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I.   INTRODUCTION 

The  Graphics  and  Video  Laboratory  of  the  Department  of  Computer  Science  at  the 
Naval  Postgraduate  School  permits  the  researcher  to  create  three-dimensional  visual 
simulations  from  digital  terrain  data  [Ref.  1].  Specialized  graphics  hardware  allows  the 
display  of  such  simulations  in  near-real  time.  The  goal  of  a  good  part  of  the  work  in  the 
lab  is  the  creation  of  a  movie-like  view  of  movement  over  and  on  terrain,  with 
increasingly  complex  movement  animation  models.  Such  projects  have  strained  the 
equipment's  capabilities.  One  method  of  increasing  available  computing  power  is  to 
harness  multiple  heterogeneous  machines  together  in  some  distributed  computing 
organization.  It  requires  communication  between  the  various  machines,  as  well  as 
carefully  matching  each  machine's  capabilities  to  its  assigned  tasks. 

A.    Problem 

Rapid  turnover  of  inexperienced  students  at  the  Naval  Postgraduate  School  makes 
the  creation  of  complex  simulations  difficult  to  manage.  The  learning  curve  becomes 
steeper  as  the  lab's  capabilities  increase.  One  of  the  areas  of  difficulty  has  been  inter- 
computer communications.  So  much  time  has  been  spent  on  designing,  coding,  and 
debugging  communication  software,  little  has  been  left  for  the  original  research.  We  set 
out  to  provide  an  easy-to-use,  yet  powerful,  set  of  tools  to  aid  in  the  development  of 
multi-computer  projects. 

1.      Approach 

A  communication  protocol  can  be  optimized  for  large  data  transfers,  or  small 
data  transfers,  or  both.  Efforts  to  optimize  for  both  are  both  complex  and  difficult 
[Refs.  2,3].  File  transfer  protocols  such  as  FTP  in  the  Defense  Advanced  Research 
Project  Agency  (DARPA)  Internet  domain  and  uucp  in  the  UNIX  domain  can  be  used  for 


large  data  transfers.  Their  overhead1  is  high.  This  overhead  cannot  be  tolerated  in  a 
real-time  problem2.  Our  visual  simulation  efforts  rely  on  small  data  transfers  to 
communicate  among  machines.  These  small  messages  are  typically  commands  and 
changing  status  indicators.  Transferring  the  entire  "world  view"  is  only  a  reasonable  task 
during  initialization  or  reset.  Hence,  we  designed  our  protocols  for  small  messages. 
2.      Design  Criteria 

The  design  criteria  for  developed  protocols  were  simplicity,  ease  of  use, 
portability,  and  efficiency.  Rapid  turnover  of  inexperienced  students  at  the  Naval 
Postgraduate  School  makes  simplicity  of  paramount  importance.  Inevitably,  changes 
will  be  required  and  only  a  simple  protocol  is  easily  modified  to  take  advantage  of  new 
capabilities.  Much  the  same  argument,  and  generally  good  software  design  practice, 
make  ease  of  use  only  slightly  less  important.  Almost  all  operating  system-level  aspects 
are  hidden  from  the  application.  The  number  of  other  machines  to  be  connected  to,  a  use 
of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  the  only 
concerns  for  the  application  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision. 

Portability  dictated  our  use  of  TCP/IP,  an  integral  part  of  the  Defense  Data 
Network  (DDN).  Efficient  use  of  processor  power  was  considered  more  important  than 
efficient  use  of  the  network  resources.  The  network  is  shared  by  the  entire  Computer 
Science  Department,  but  is  not  heavily  loaded. 


1  The  cost  of  creating  a  file  and  then  spawning  a  process  to  send  it  is  high.  On  the  receiving  end,  there  is  the  cost 
of  creating  the  file  and  then  reading  it.  Even  a  zero-cost  file  transfer  protocol  will  require  all  this  overhead. 

2  Large  data  transfers,  in  real-time  systems,  will  not  be  possible  until  100  MByte/Sec  networks  are  commonly 
available. 


B.   BACKGROUND 

1.      Visual  Simulation 

a.      Vision  and  Information  Presentation 

The  eye  has  the  largest  bandwidth  of  any  human  sensory  organ.  Proper 
use  of  this  capability  is  a  challenge  to  all  scientists.  Static  graphs  are  used  in  most 
disciplines  to  show  the  relationships  between  a  limited  number  of  variables.  These  two- 
dimensional  representations  convey  information  more  readily  to  human  beings  than 
would  a  table  of  the  underlying  numbers.  [Ref.  4:  pp.  8-12] 

Time,  a  common  independent  variable,  is  often  one  dimension  on  a  graph. 
The  other  dimension  is  a  single  dependent  variable.  To  portray  additional  variables  in 
one  presentation  is  a  frequently  occurring  requirement.  Various  techniques  such  as 
multiple  colored  lines,  multiple  icons,  and  perspective  drawing  are  used.  With  each 
technique,  only  a  few  additional  variables  are  added  before  the  graph  becomes 
incomprehensible . 

Pictures,  particularly  those  in  color,  have  a  dense  information  content. 
Unless  blind,  we  live  in  a  world  of  pictures.  Human  beings  can  recognize  many 
differences  between  two  similar  pictures.  One  presentation  portrays  many  different 
variables.  When  a  series  of  pictures  are  presented,  the  time  variable  is  easily  correlated 
to  the  actual  time  of  presentation.  When  a  series  of  pictures  is  presented  rapidly,  the 
experience  approaches  reality,  partly  explaining  the  success  of  moving  pictures  and 
television. 

Animation  creates  visual  images  with  an  explicit  time  dimension,  in 
addition  to  two  or  three  spatial  dimensions.  Using  actual  time  to  portray  the 
experimental  time  variable  allows  at  least  one  more  dependent  variable  on  the  display. 
Images  can  be  as  simple  as  a  changing  graph,  or  as  complex  as  a  feature-length  cartoon. 


However,  animation  creates  its  effect  with  the  playback  of  prerecorded  scenes  [Ref.  5]. 
It  is  not  suitable  for  providing  immediate  feedback  to  a  researcher. 

b.  Definition 

Visual  simulation  is  the  creation,  by  computer,  of  a  realistic,  easily- 
modified,  moving  image  from  the  mathematical  model  of  a  phenomenon.  Realism 
implies  high-resolution,  color  graphics.  Movement  implies  adequate  floating  point 
calculation  capacity  to  recalculate  the  model  and  its  graphical  representation  between 
display  refresh  cycles.  Easy  modification  implies  a  well-designed  computer  application. 

Visual  simulation  allows  a  researcher  to  experiment  easily  with  his 
subject.  Ideally,  we  display  a  realistic  approximation  of  part  of  the  world.  The 
experimenter  then  manipulates  some  part  of  this  visual  simulation  and  receives 
immediate  visual  feedback.  The  rapidly  refreshed  display  is  one  key  to  visual  realism. 
Such  a  display  allows  the  direct  manipulation  of  the  visual  simulation,  making  it  easy 
and  intuitive  to  use  [Ref.  6].  Ease  of  use  allows  the  researcher  to  concentrate  on  the 
research  question,  not  the  display  methodology  or  the  computer  interface. 

c.  Examples 

Recent  visual  simulation  projects  of  the  Graphics  and  Video  Laboratory 
include  speed  control  of  autonomous  vehicles  [Ref.  7],  control  of  autonomous  walking 
machines  [Ref.  8],  rule-based  control  of  autonomous  underwater  vehicles  [Ref.  9], 
interactive  moving  platforms  [Ref.  10]  and  combat  vehicle  control  [Ref.  11].  Each  of 
these  projects  exceeded  the  capacity  of  a  single  workstation.  The  speed  control  and 
interactive  moving  platform  projects,  written  entirely  in  C,  used  two  Silicon  Graphics, 
Inc.  IRIS  workstations,  allowing  multiple  simultaneous  views.  The  other  projects  all 
required  a  rule-based  artificial  intelligence  component,  best  programmed  in  Lisp  for  ease 
of  modification.  Running  the  Lisp  subsystem  on  the  IRIS  workstation  gave  an 
unacceptably  low  refresh  rate  and  correspondingly  poor  realism  [Ref.  12].    Placing  the 


Lisp  subsystem  on  another  machine  improved  the  refresh  rate  of  the  IRIS  workstation 
used  for  the  graphics  display. 

2.      Computer  System  Architecture 

Computer  systems  can  have  a  distributed  or  a  non-distributed  architecture. 
Distributed  architectures  have  only  one  characteristic  in  common,  more  than  one 
processor  used  to  accomplish  the  task.  Beyond  this,  many  different  approaches  have 
been  tried  [Ref.  13].  Identical  processors  give  a  homogeneous  architecture.  Different 
processors  give  a  heterogeneous  architecture.  Either  distributed  architecture  may 
incorporate  shared  memory  or  it  may  not.  The  separate  processors  can  be  closely  or 
loosely  coupled.  Communication  between  processors  can  be  via  shared  memory, 
common  bus,  or  some  form  of  communications  network.  Communication  via  some 
combination  of  the  above,  such  as  a  file  server  on  a  local  area  network,  is  also 
common  [Ref.  3].  In  the  Computer  Science  Department  at  the  Naval  Postgraduate 
School,  a  heterogeneous  mix  of  stand-alone  workstations,  file  server  supported 
workstation  clusters,  and  minicomputers  communicates  via  Ethernet. 

Programming  distributed  architectures  has  inspired  creativity.  The 
fundamental  problems  with  distributed  programming  are  the  communications  between 
processes  and  the  temporal  interaction  of  the  processes.  Communicating  sequential 
processes  [Ref.  14],  distributed  processes  [Ref.  15],  and  remote  procedure  calls 
[Refs.  2, 16]  have  all  been  proposed  as  primitives  to  hide  message  passing  from  the 
programmer.  Remote  procedure  calls  [Refs.  2, 3]  and  communicating  sequential 
processes  [Ref.  17]  have  been  implemented.  However,  even  today,  none  of  these  is 
generally  available  as  a  standard  mechanism  across  varied  architectures.  We  have 
created  simpler  (but  less  general)  communication  routines  for  use  among  heterogeneous, 
distributed,  standalone  computers. 


Complex  projects  can  require  the  resources  of  more  than  one  computer. 
Graphics  portions  are  best  handled  by  the  specialized  hardware  of  a  graphics  workstation, 
such  as  a  Silicon  Graphics,  Inc.  IRIS.  Artificial  intelligence  portions  are  best  handled  by 
a  Lisp  machine,  such  as  a  Symbolics  or  a  Texas  Instruments  Explorer  .  Database 
requests  can  be  made  to  a  machine  with  appropriate  database  software.  A  general 
purpose  computer,  such  as  the  Digital  Equipment  Corporation  VAX  ,  can  be  used  for 
additional  processing  power,  file  storage,  or  other  administrative  support.  Providing  easy 
access  across  such  a  mix  of  heterogeneous  computers  is  a  large  task  [Ref.  3].  The  simple 
mechanism  described  in  this  work  gives  communication  access  between  cooperating 
processes  running  on  diverse  hardware.  It  leaves  temporal  design  to  the  application 
developer,  while  providing  the  tools  for  synchronous  and  asynchronous  interaction. 
3.      Communication 

Communications  between  computers  cooperating  on  a  task  can  be  one-to-one, 
many-to-one,  or  one-to-many.  It  can  be  synchronous  or  asynchronous.  Any,  or  all,  of 
these  can  be  required  for  one  visual  simulation. 

One-to-one,  or  direct  connect,  communications  puts  the  lowest  load  on  the 
network  when  there  are  few  messages  to  be  sent.  A  single  virtual  channel  between  the 
two  processes  is  required.  Each  communication  between  any  two  processes  comprises 
one  message.  All  messages  are  known  to  be  intended  for  the  receiving  process.  These 
messages  can  be  sent  synchronously  or  asynchronously.  Direct  connect  communication 
requires  one  action  by  the  sender  and  one  by  the  receiver.    With  more  processors, 


Symbolics  is  a  trademark  of  Symbolics,  Incorporated. 
*  Explorer  is  a  trademark  of  Texas  Instruments  Incorporated. 
"  VAX  is  a  registered  trademark  of  Digital  Equipment  Corporation 


potential  virtual  channels  grow  in  number  geometrically.  For  a  fully  connected  network, 
the  virtual  channels  required  can  exceed  capacity.  The  potential  messages  required  also 
grow  geometrically  in  number. 

One-to-many,  or  broadcast,  communications  puts  the  lowest  load  on  the 
sending  process.  A  message  is  sent  to  all  other  processes  that  are  connected  to  it.  It 
requires  one  action  by  the  sender,  and  two  actions  by  each  receiver  (the  reception  and  a 
decision  on  whether  the  message  is  intended  for  that  receiver).  It  also  places  one  to  n 
messages  on  the  network  (depending  on  how  the  network  and  the  broadcast  protocols  are 
designed).  It  is  primarily  used  in  an  asynchronous  mode,  although  synchronous  protocols 
could  be  designed. 

Many -to-one  communications  puts  the  highest  load  on  the  receiving  process.  It 
requires  two  actions  by  the  receiver  on  every  message  that  is  sent  by  any  connected 
process.  It  is  also  a  primarily  asynchronous  method.  The  receiver  portion  of  a  process 
sees  many-to-one  whenever  broadcast  protocols  are  the  only  ones  used  in  a  visual 
simulation. 

C.    Organization 

The  previous  sections  of  this  chapter  provide  background  on  visual  simulation, 
distributed  architectures,  and  communication  paradigms.  Chapter  II  describes  the 
hardware  and  software  environment  in  the  Computer  Science  Department  at  the  Naval 
Postgraduate  School.  The  protocols  developed  are  discussed  in  Chapter  III.  Chapter  IV 
describes  the  implementation  of  the  protocols.  Chapter  V  covers  the  use  of  these 
protocols.  The  performance  of  the  protocols  is  detailed  in  Chapter  VI.  Chapter  VII 
concludes  with  a  discussion  of  limitations,  future  extensions  and  research  topics,  and 
summarizes  the  research  conducted.  Listings  of  the  program  source  code  for  each  of  the 
hardware  systems  are  included  as  Appendices. 


n.  Existing  System 

A.    Introduction 

The  distributed  architecture  available  in  the  Naval  Postgraduate  School  Computer 
Science  Department  Graphics  and  Video  Laboratory  is  Ethernet-connected  workstations 
and  minicomputers.    The  workstations  include  IRIS  2400,  3120,  and  4D  graphics, 

Symbolics  36xx   and  TI  Explorer  Lisp,  ISI AI,  and  Sun-3s    .  The  minicomputers  include 
VAX   11/785   and  an  ISIV  minicomputer  complex  providing  database  services.    All 

computers,  except  the  Symbolics  and  TI,  use  some  version  of  UNIX       as  the  primary 
operating  system. 

B.      HARDWARE 

1.      Network 

Ethernet  connects  all  the  computers  in  our  lab.  There  is  a  backbone  network 
and  subnetworks  for  certain  groups  of  computers.  Currendy  there  are  two  subnetworks, 
one  for  the  ISIV  minicomputers  and  one  for  the  ISI  AI  workstations.   Subnetworks  are 

planned  for  the  IRIS  workstations,  the  Sun  Workstations       ,  and  the  Symbolics  and  TI 
workstations.  Figure  2.1  illustrates  the  network  configuration. 


*  Symbolics  3600,  Symbolics  3640,  Symbolics  3650,  and  Symbolics  3675  are  trademarks  of  Symbolics,  Inc. 
**  Sun-3  is  a  trademark  of  Sun  Microsystems,  Inc. 
UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 
Sun  Workstation  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 
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Figure  2.1     Network  Configuration 


All  computers  support  TCP/IP  protocols.  The  Symbolics  Lisp  machines  also 
use  the  CHAOS  protocol  to  provide  file  server  services  from  syml  to  the  other  Symbolics 
machines.  This  logical  local  area  network  (LAN)  uses  the  Ethernet  backbone  for  its 
messages.  The  Sun  file  servers  also  support  their  diskless  nodes  over  the  backbone 
Ethernet. 

2.      Workstations 

a.  Silicon  Graphics,  Inc.  IRIS 

Table  2.1  shows  the  IRIS  workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  proprietary  Geometry  Engines  in  each  of  these 
workstations  allows  three  dimensional  color  graphics  displays  to  be  generated  and 
updated  in  real-time.  The  primary  use  of  these  machines  is  for  color  graphics. 

b.  ISI AI 

Table  2.2  shows  the  ISI  AI  workstation  configurations.  Only  ai8  is 
connected  directly  to  the  backbone  Ethernet.  The  other  workstations  are  connected  to  it 
in  a  subnetwork.  These  workstations  are  used  primarily  for  artificial  intelligence 
projects.  The  ai8  machine  provides,  as  well  as  a  gateway  to  the  backbone  Ethernet,  file 
server  support  for  the  other  workstations.  Their  high  resolution  black  on  white  monitors, 
although  bitmapped,  have  rudimentary  graphics  capabilities. 


Table  2.1 

IRIS  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 
No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 
Planes 

Floating 

Point 

Accelerator 

Screen 
Resolution 

irisl 
iris2 
iris3 
iris4 

4D/70G 

2400  Turbo 

3120 

4D/70G 

8 
6 
4 
8 

380MB 
144MB 
144MB 
380MB 

56 

32 
32 
56 

N/A 
Y 

N 
N/A 

1280x1024 
1024x768 
1024x768 
1280x1024 

10 


Table  2.2     ISI  AI  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 

No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 
Planes 

Screen 
Resolution 

ail 

V8WS 

4 

101MB 

2 

1280x1024 

ai2 

V8WS 

4 

101MB 

2 

1280x1024 

ai3 

V8WS 

4 

101MB 

2 

1280x1024 

ai4 

V8WS 

4 

101MB 

2 

1280x1024 

ai5 

V8WS 

4 

101MB 

2 

1280x1024 

ai6 

V8WS 

4 

101MB 

2 

1280x1024 

ai7 

V8WS 

4 

101MB 

2 

1280x1024 

ai8 

V16WS 

4 

403MB 

2 

1280x1024 

c.  Sun-3/50 

Table  2.3  shows  the  Sun  Workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  black-on-white  monitors  of  the  Sun  diskless 
workstations  are  primarily  used  for  administrative  tasks  at  this  time. 

d.  Symbolics  36xx 

Table  2.4  shows  the  Symbolics  workstation  configurations.  All  are 
connected  direcdy  to  the  backbone  Ethernet.  The  Symbolics  workstations  are  used  for  a 

Table  2.3     SUN  WORKSTATION  CONFIGURATIONS 


Niplrnsimf" 

Model 

Memory 

Disk 

Bit 

Screen 

No. 

(MBytes) 

Capacity 

Planes 

Resolution 

sunsl 

3/1 80S 

12 

490MB 

2 

1280x1024 

sun  10 

3/50 

4 

N/A 

2 

1280x1024 

sunll 

3/50 

4 

N/A 

2 

1280x1024 

sun  12 

3/110 

4 

N/A 

2 

1280x1024 

sun  13 

3/110 

4 

N/A 

2 

1280x1024 

sun  14 

3/60 

4 

N/A 

2 

1280x1024 

sun  15 

3/60 

4 

N/A 

2 

1280x1024 

sun  16 

3/60LC 

4 

N/A 

10 

1280x1024 

sun  17 

3/50 

4 

N/A 

2 

1280x1024 

sunl8 

3/50 

4 

N/A 

2 

1280x1024 

sun  19 

3/50 

4 

N/A 

2 

1280x1024 

suns2 

3/1 80S 

12 

490MB 

2 

1280x1024 

sun20 

3/60LC 

4 

N/A 

10 

1280x1024 

sun21 

3/60LC 

4 

N/A 

10 

1280x1024 

11 


Table  2.4     SYMBOLICS  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 

Capacity 

Bit 
Planes 

Color 

Screen 
Resolution 

syml 
sym2 
sym3 
sym4 

3675 
3640 
3640 
3650 

5 
1 
1 
5 

1GB 
180MB 
180MB 
512MB 

24 
1 
8 
1 

Y 

N 
Y 

N 

1280x1024 
1280x1024 
1024x1024 
1280x1024 

variety  of  research  projects  involving  artificial  intelligence.  The  syml  machine  provides 
file  server  support  for  the  other  Symbolics  machines  using  the  Chaos  protocol  and  its  one 
GigaByte  (unformatted)  storage  capacity.  The  color-capable  systems  are  used  to  display 
static  information  with  color  providing  an  easier  human  interface, 
e.      Texas  Instruments  Explorer 

Table  2.5  shows  the  Explorer  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  TI  Explorers  are  also  used  for  artificial 
intelligence  projects.  They  have  the  least  graphical  capabilities  of  any  of  the 
workstations. 

3.      Digital  Equipment  Corporation  VAX  11/785 

Table  2.6  shows  the  two  DEC  VAX  11/785  computer  configurations.  Both  are 
connected  direcdy  to  the  backbone  Ethernet.  Only  the  unixl  machine  was  included  in 
this  project.    The  vmsl  machine  may  not  be  available  in  the  future,  so  the  effort  to 


Table  2.5     EXPLORER  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 
No. 

Memory 

(MBytes) 

Disk 
Capacity 

Bit 

Planes 

Screen 
Resolution 

expl 
exp2 
exp3 
exp4 

I 
I 
I 
I 

4 
8 
8 

2 

280MB 
420MB 
420MB 
140MB 

1 
1 
1 
1 

1024x808 
1024x808 
1024x808 
1024x808 

*  DEC  is  a  registered  trademark  of  Digital  Equipment  Corporation 
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Table  2.6     VAX  CONFIGURATIONS 


Nickname 

Model 

No. 

Memory 

(MBytes) 

Disk 
Capacity 

Operating 
System 

unixl 
vmsl 

11/785 
11/785 

24 
8 

1395MB 
1442MB 

UNIX 

VMS 

develop  appropriate  code  was  deemed  unnecessary.   The  unixl  machine  is  nps-cs.arpa 
on  MILNET  and  is  the  sole  external  access  point  to  other  machines  connected  locally  via 
Ethernet.  It  supports  the  various  dial-up  lines,  as  well  as  other  administrative  functions. 
4.      IS  IV  minicomputers 

The  computers  in  Table  2.7  make  up  the  ISIV  minicomputer  complex.  Only 
isiv8  is  connected  to  the  backbone  Ethernet.  The  other  machines  are  connected  to  isiv8 
in  an  Ethernet  subnetwork.  The  ISIV  minicomputers  provide  a  high  performance,  multi- 
backend  distributed  database.  Any  of  the  high-resolution  black  on  white  monitors  can  be 
used  with  any  of  the  hosts  on  the  subnetwork.  The  character  displays  can  also  be  used  on 
any  of  the  subnetwork  hosts.  The  graphics  capabilities  of  these  machines  are  limited. 


Table  2.7     ISIV  DATABASE  MACHINE  CONFIGURATION 

Nickname 

Model 

Memory 

Disk 

Bit 

Screen 

No. 

(MBytes) 

Capacity 

Planes 

Resolution 

isivl 

V24S 

4 

602MB 

N/A 

80x24char 

isiv2 

V24WS 

4 

500MB 

2 

1280x1024 

isiv3 

V24WS 

4 

602MB 

2 

1280x1024 

isiv4 

V24WS 

4 

500MB 

2 

1280x1024 

isiv5 

V24S 

4 

602MB 

N/A 

80x24char 

isiv6 

V24S 

4 

602MB 

N/A 

80x24char 

isiv7 

V24WS 

4 

602MB 

2 

1280x1024 

isiv8 

V24WS 

4 

459MB 

2 

1280x1024 

isiv9 

V24S 

4 

602MB 

N/A 

80x24char 
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C.    Software 

1.  UNIX  Machines 

Two  versions  of  UNIX  are  commonly  used.  The  machines  purporting  to  use 

System   V  ,   also   incorporate   characteristics    of  4.2BSD   and  4.3BSD.    The   relevant 
incorporation  is  the  Berkeley  socket  mechanism. 

a.  4.3BSD 

A  "pure"  4.3BSD  system  (4.3  BSD  UNIX  #11)  exists  only  on  unixl.  The 
IS IV  minicomputers  use  4.2  BSD  UNDC  Release  3.07,  with  a  multi-backend  database 
system  installed  [Refs.  18-20].  The  ISI  AI  workstations  use  IS68K  4.3  BSD  UNDC:  4.0D 
#2. 

b.  System  V 

The  IRIS  4D  systems  use  UNDC  System  V-based  version  4D  1-2.2.  The 
IRIS  2400  and  3120  systems  use  UNDC  System  V-based  version  GL2-W3.6.  Both  have 
extensive  4.3BSD  extensions.  The  Sun-3  uses  an  almost  System  V  version  of  4.2BSD 
UNDC.  The  currently  installed  release  is  3.4. 

2.  Lisp  Machines 

a.  Genera 

The  Symbolics  Lisp  Machines  first  used  Genera  6.0  software.  All 
machines  are  now  on  Genera  7.1. 

b.  Explorer 

The  TI  Explorer  lisp  machine  first  used  Explorer  version  1.0.2  software. 
All  machines  are  now  on  version  3.4  except  expl ,  which  is  still  on  version  3.2. 


UNDC  System  V  is  a  trademark  of  AT&T  Bell  Laboratories 
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D.      SUMMARY 

The  configuration  described  above  is  constantly  changing.  Additional  machines  are 
acquired.  Older  machines  receive  hardware  upgrades.  The  network  is  reconfigured. 
Software  releases  are  updated  (especially  4.2BSD  UNIX  to  4.3BSD  UNIX).  The 
fundamental  needs  for  distributed  computation  in  this  heterogeneous  environment 
remain. 
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m.  Protocols 

A.  Introduction 

Our  visual  simulation  efforts  rely  on  small  data  transfers  to  communicate  among 
machines.  These  small  messages  are  typically  commands  and  changing  status  indicators. 
Hence,  we  optimized  our  protocols  for  small  messages.  Overhead  to  optimally  encode 
and  decode  packets  was  deemed  inappropriate.  The  design  criteria  for  developed 
protocols  were  simplicity,  ease  of  use,  portability,  and  efficiency. 

B.  Direct  Connection 

The  client/server  paradigm  is  used  for  direct  connection.  The  client  requests 
services  from  the  server,  so  establishing  communications  is  asymmetrical.  Once 
communications  are  established,  however,  the  protocol  used  is  completely  symmetrical. 
[Ref.  21:  p.  17] 

1.      High-Level  Protocol 

The  variety  of  data  types  supported  is  limited  (see  Table  3.1).  Each  message 
contains  exactly  one  instance  of  one  type  of  data.  All  integer  or  float  data  is  converted  to 
an  ASCII  character  string  before  it  is  sent.   It  is  converted  back  to  the  proper  type  after 

Table  3 . 1     DATA  TYPES  SUPPORTED 


Type 

Length 

(Bytes) 

Elements 

Code 

Available 

character 

1 

single 

B 

Y 

array 

C 

Y 

integer 

4 

single 

I 

Y 

array 

J 

N 

float 

4 

single 

R 

Y 

array 

S 

N 
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reception.  While  the  conversion  is  unnecessary  when  communicating  between  similar 
architectures,  it  greatly  simplifies  the  task  of  communicating  between  fundamentally 
different  architectures.  Knowledge  of  the  other  machine's  architecture  is  not  required. 
The  inherent  portability  of  this  solution  outweighs  the  processing  cost. 

A  message  is  created  with  three  fields.  The  type  field  is  a  one-character  field. 
It  contains  the  appropriate  code  from  Table  3.1.  The  length  field  is  a  four-character  field. 
It  contains  an  ASCII  string  from  0001  to  9999.  This  string  gives  the  length  of  the  data 
field.  The  data  field  is  a  variable  length  field  containing  the  ASCII  representation  of  the 
data  element.  Figure  3.1  illustrates  these  fields. 

While  C  programmers  are  continuously  concerned  with  data  types,  Lisp 
programmers  are  not.  The  Lisp  routines  support  arrays  of  characters,  single  integers,  and 
single  floating  point  numbers.  Each  of  these  is  an  object.  Objects,  not  types  (as  implied 
in  Table  3.1),  are  received  and  sent  by  lisp  applications.  The  underlying  protocol  is  the 
same,  the  application  interface  is  different3. 


Position 


1 

2 

3        4 

5 

6 

7 

n 

T 

y 
p 

Length 

Data 

e 

Figure  3.1     Message  Format 


3  Giapter  5  discusses  applications'  use. 
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2.      Supporting  Protocols 

Full-duplex  stream  sockets  are  used  to  provide  sequenced,  reliable  connection 
between  machines.  The  sockets  are  created  in  the  DARPA  Internet  domain.  The 
Internet  pseudo-protocol  is  used  [Ref.  22].  No  out-of-band  capability  was  included.  We 
could  not  envision  a  use  for  it,  since  our  protocol  is  inherently  asynchronous.  If  a  strictly 
synchronous  protocol  was  used,  out-of-band  transmission  might  be  necessary  to  interrupt 
for  an  urgent  message.  In  an  asynchronous  protocol,  however,  encoding  the  next 
message  gives  the  same  effect.  Processing  overhead  for  encoding  is  no  greater  than  for 
continuous  monitoring  for  an  out-of-band  message.  With  only  a  small  volume  of  data 
transfers  expected,  no  urgent  message  waits  very  long. 

Two  ports,  each  with  its  own  stream  socket,  are  used  for  each  channel  between 
machines.  Although  full-duplex,  the  stream  sockets  are  used  in  a  simplex  mode.  The 
separate  sockets  are  used  because  two  processes  cannot  be  bound  to  the  same  socket  at 
the  same  time.  Two  separate  UNIX  processes  then  monitor  the  independent  send  and 
receive  sockets.  Blocking  sockets  are  used,  avoiding  processing  overhead  for  busy- 
waiting.  While  non-blocking  sockets  are  available  in  4.3BSD  [Ref.  21:  p.  25],  they  were 
not  explicitly  available  in  4.2BSD  [Ref.  22].  Operating  systems  might  include  4.2BSD 
sockets  rather  than  4.3BSD  versions  and  so  the  blocking  socket  mechanism  was  deemed 
more  portable.  Both  TCP/IP  and  the  C  routines  provide  buffering. 

On  the  TI  Explorer,  sockets  were  also  blocking5.  Direct  access  was  made  to 
the  TCP  methods  provided.   Lisp  streams  are  used  for  the  Symbolics  lisp  routines.   The 


4  This  is  the  underlying  mechanism  of  the  Defense  Data  Network  (DDN)  and  was  chosen  for  its  wide  availability 
and  applicability  to  Department  of  Defense  problems. 

5  Version  1.0  of  the  Explorer  TCP/IP  software  uses  blocking  sockets.   Version  2.0  uses  non-blocking  sockets. 
There  has  been  no  update  of  this  system's  TI  Explorer  lisp  routines  to  version  2.0. 
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lisp  stream  mechanism  isolates  the  code  from  the  issues  revolving  around  blocking 
versus  non-blocking  sockets. 

C.      BROADCAST 

A  broadcast  message  is  sent  to  all  machines  on  a  local  Ethernet.  Those  machines 
that  are  waiting  for  some  broadcast  message  will  probably6  receive  it.  If  a  machine  on  a 
subnetwork  is  to  get  a  broadcast  message,  an  application  must  run  on  the  gateway 
machine  that  will  rebroadcast  on  the  subnetwork  any  messages  received  on  the  backbone 
Ethernet.  Machines  not  expecting  a  broadcast  message  must  nevertheless  process  it  and 
reject  it  as  inappropriate.  The  extra  load  on  all  machines  connected  to  the  Ethernet 
restricts  broadcasting  to  infrequent  occurences  until  most  of  the  machines  used  in 

simulations7  are  on  a  private  subnetwork. 

1.  High-Level  Protocol 

We  expect  users  of  the  broadcast  protocol  to  mix  its  use  with  the  use  of  direct 
connections.  The  same  data  types  and  messages  are  supported  (see  Table  3.1). 

2.  Supporting  Protocols 

Full-duplex  datagram  sockets  are  used  to  provide  connectionless  broadcast 
capability.  The  sockets  are  created  in  the  DARPA  Internet  domain.  As  with  our  use  of 
stream  sockets  for  the  direct  connection  protocol,  we  use  these  full-duplex  datagram 
sockets  in  a  simplex  mode.  We  use  a  sending  socket  for  one-way  sending  of  a  broadcast 
message  to  all  other  machines  on  a  single  network  or  subnetwork.  We  use  a  receiving 
socket  for  one-way  receiving  from  a  specific  broadcasting  machine  on  the  network  or 


6  Unlike  the  direct  connect  protocol,  the  broadcast  protocol  does  NOT  guarantee  reception.  Trying  to  provide 
such  a  guarantee  requires  a  feedback  machanism  so  that  the  sender  knows  that  the  machines  expected  to  receive  the 
broadcast  did  so.  This  is  difficult  without  resorting  to  a  direct  connection  or  flooding  the  network  with  messages. 

7  The  IRIS  machines  and  the  Lisp  machines  are  the  ones  principally  used  for  visual  simulation. 
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subnetwork.    Direct  connection,  with  its  use  of  guaranteed  reliable  stream  sockets,  is 
used  for  any  other  communication,  including  return  messages.   [Ref.  21:  pp.  32-34] 

As  in  the  direct  connection  protocol,  independent  UNIX  processes  are  bound  to 
the  sockets.  Since  broadcasting  is  a  one-way  activity,  a  sender  or  receiver  only  spawns 

a 

one   UNIX  process. 

D.      SUMMARY 

By  building  our  high-level  protocols  on  top  of  DARPA  TCP/IP  standards,  we  provide 
the  highest  degree  of  portability  possible  today.  By  using  full-duplex  stream  sockets  and 
datagram  sockets  in  a  simplex  mode,  we  do  not  make  full  utilization  of  a  socket's 
capabilities.  However,  this  concern  is  outweighed  by  the  increased  simplicity  and 
resultant  maintainability  of  the  code.  The  use  of  ASCII  character  strings  for  the  messages 
is  simple  and  makes  interconnection  with  diverse  architectures  straightforward. 


8  If  broadcasting  were  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  n  processes. 
If  direct  connection  was  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  2n-2  processes. 
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IV.  Implementations 
a.    Introduction 

The  first  connection  was  between  the  IRIS  2400-Turbo  and  TI  Explorer.  Then  the 
Symbolics  Lisp  machines  were  included.  These  routines  have  had  extensive  use 
[Refs.  8,9, 11].  The  IRIS  functions  were  updated  for  the  IRIS  4D,  coincidentally 
providing  Mex  support  on  the  older  IRIS  machines.  Broadcast  capability  was  added  for 
UNIX-based  machines.  A  port  to  4.3BSD  UNIX  (application  calls  unchanged)  was  begun. 

B.      SYSTEM  V  UNIX 

All  our  System  V  UNIX-based  systems  include  the  socket  mechanism  first 
introduced  by  4.2BSD.  Sockets  are  a  key  aspect  of  all  implementations.  We  expect  they 
will  become  part  of  System  V  or  its  successors  [Ref.  23].  The  System  V-unique 
semaphore  and  shared  memory  interprocess  communication  (IPC)  capabilities  are  also 
used. 

1.      Silicon  Graphics,  Inc.  IRIS  2400 
a.      Sockets 

The  socket  was  introduced  in  4.2BSD  as  the  preferred  metaphor  for  IPC.  It 
was  easy  and  efficient  to  implement  and  the  select  mechanism  could  be  used  to 
implement  remote  procedure  calls,  if  desired  [Ref.  23].  System  V  had  no  comparable 
mechanism  until  version  3  was  released  with  streams.   The  BSD  sockets  were  included 

by  many  vendors,  Silicon  Graphics,  Inc.  included  .   While  the  use  of  sockets  could  be 


9  The  System  V  version  available  on  the  IRIS  machines,  at  the  start  of  the  project,  was  version  2  and  so  streams 
were  not  considered. 
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replaced  with  streams,  device  drivers  would  have  to  be  written.  The  advantage  of 
streams  is  the  ability  to  filter  them  between  streamhead  and  the  actual  device  driver. 
These  filters,  however,  reside  in  the  kernel's  address  space  and  have  the  kernel's 
permissions  [Ref„  241.  In  our  environment,  the  potential  performance  increase  is  not  as 
important  as  the  requirement  for  simplicity. 

The  system  call  for  socket  creation  is  socket.  The  system  calls  supporting 

socket  configuration  are  setsockopt,  bind,  connect,  and  accept10  [Ref.  22].  To  simplify 
their  use,  these  are  all  repackaged  into  four  high  level  routines:  connect _server  and 
connect _client  for  direct  connection,  start  broadcast  and  broadcast jreceive  for 
broadcast.  These  routines  are  encapsulated  in  netV.c.  netV.c  can  be  separately  linked 
with  any  application  that  needs  to  make  a  server/client  connection  using  stream  sockets 
or  a  broadcasting  connection  using  datagram  sockets.  Table  4.1  describes  the  four 
routines. 

Using  the  socket  number  ,  a  process  can  transmit  data  through  the  socket. 
In  our  system,  sockets  for  inter-computer  communication  are  created  and  used  by  the 
send  and  receive  processes  exclusively.  The  file  netV.c  is  not  linked  with  the  application 
at  all. 


10  The  accept  system  call  is  only  relevant  to  stream  sockets.  The  setsockopt,  bind,  and  connect  system  calls  are 
used  with  both  stream  sockets  and  datagram  sockets. 

In  the  direct  connect  protocol,  the  server  process  reads  from  and  writes  to  a  remote  socket  number.  The  client 
process  reads  from  and  writes  to  its  local  socket  number.  The  reason  for  this  is  that  a  server  could  be  connected  to  dif- 
ferent clients  (although  not  in  our  implementation)  at  different  times.  The  client,  meanwhile,  is  only  going  to  connect 
to  the  one  server.  In  the  Internet  domain,  all  necessary  routing  information,  for  either  server  or  client,  is  contained  in  a 
sockaddrjn  structure  and  is  accessed  (transparently)  via  the  socket  number. 

In  the  broadcast  protocol,  both  the  broadcaster  and  receiver(s)  use  their  local  socket  number  because  they  are 
using  connectionless  datagram  sockets.  The  routing  information  is  also  contained  in  a  sockaddrjn  structure. 
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Table  4. 1     SOCKET  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

connect_server 

Creates    socket.     Binds    that 
socket   to   remote   client   ad- 
dress and  port.    Waits  to  ac- 
cept the   remote  client  con- 
nection.   Returns  the  socket 
number  for  the  remote  client. 

int  connect_server(.  remote_client_name,  port_number  ) 
char  remote_client_name[]; 
int  port_number, 

remote_socket  =  connect_server(  remote_client_name, 

port_number  ) 

connect_client 

Creates    socket.     Binds    that 
socket  to  remote  server  ad- 
dress   and    port.     Connects 
with  remote  server.    Returns 
the  local  socket  number. 

int  connect_client(  remote_server_name,  port_number  ) 
char  remote_server_name[]; 
int  port_number, 

local_socket  =  connect_client(  remote_server_name, 

port_n umber  ) 

start_broadcast 

Creates    socket.     Sets    it    to 
broadcast  mode.    Binds  it  to 
local    address    and    specified 
local  port.    Returns  the  local 
socket  number. 

int  start_broadcast(  port_number ) 

int  port_number; 

local_socket  =  start_broadcast(  port_number  ) 

broadcast_receive 

Creates  socket.    Binds  it  to 
local    address   and   specified 
port.     Adds   broadcaster  ad- 
dress and  port.    Returns  the 
local  socket  number. 

int  broadcast_receive(  broadcaster_name,  broadcaster_port  ) 
char  broadcaster_name[]; 
int  broadcaster_port; 

local_socket  =  broadcast_receive(  broadcaster_name, 

broadcaster_port  ) 

b.      Semaphores 

The  semaphore  mechanism  was  chosen  as  the  least  expensive,  in  both 
space  and  time,  for  communication  between  processes.  Signals  could  have  been  used, 
but  implementation  would  have  been  more  complex  and  less  reliable.  Signal-based 
communication  functions  would  also  have  been  more  difficult  for  the  application 
programmer  to  use  [Ref.  25:  p.  10].  There  are  two  semaphore  ids  maintained  for  each 
connection12.  One  is  used  to  communicate  with  the  send  process;  one  is  used  to 
communicate  with  the  receive  process.  The  two  semaphores  are  both  used  to  signal  theii 
process  when  it  is  safe  to  proceed.   A  send  process  is  permitted  to  proceed  only  after  the 


12  Two  semaphore  ids  are  required  for  direct  connect  protocol  connections  since  both  a  send  and  a  receive  pro- 
cess are  spawned.  Two  semaphore  ids  are  still  created  for  broadcast  protocol  connections,  even  though  only  one  pro- 
cess is  spawned. 
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application  has  requested  a  write  action  on  the  channel.  A  receive  process  is  permitted 
to  proceed  only  after  the  application  has  read  all  data  from  the  shared  memory  buffer. 
Neither  the  send  nor  the  receive  process  is  executing  more  than  absolutely  necessary, 
assuring  maximum  availability  of  the  local  processor  to  the  application. 

The  system  calls  supporting  semaphores  are  semget,  semop,  and  semctl. 
To  simplify  their  use,  they  are  repackaged  into  three  high  level  routines:  semtran,  P,  and 
V  [Ref.  25:  pp.  188-190].  These  routines  (and  a  support  routine  semcall)  are 
encapsulated  in  semaphores.  It  can  be  separately  linked  with  any  application  that  needs 
semaphores.  Table  4.2  describes  the  three  routines. 
c.      Shared  Memory 

A  cost  barrier  to  IPC  in  UNIX  is  the  cost  of  copying  data  from  one  process 
to  the  kernel  and  then  from  the  kernel  to  another  process.  Using  a  shared  memory 
segment,  as  a  buffer,  rninimizes  this  overhead.  To  further  reduce  overhead  from  system 
calls,  only  a  single  segment  is  created.  An  application  accesses  the  entire  segment,  while 
a  send  or  receive  process  accesses  only  its  preassigned  section.  Figure  4.1  displays  the 
layout.  The  message  area  of  each  section  is  used  for  several  purposes.  It  is  formatted  as 

Table  4.2     SEMAPHORE  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

semtran 

Creates  a  semaphore  associ- 
ated with   a  key.    Returns  a 
semaphore  id. 

int  semtran(  key  ) 

int  key; 

sid  =  semtran(  key  ); 

P 

Acquire  semaphore 

void  P(  sid ) 
int  sid; 

V 

Release  semaphore 

void  V(  sid  ) 
int  sid; 

13  The  data  must  also  be  valid  in  the  shared  memory  buffer.  All  this  is  transparent  to  the  application,  which  only 
issues  a  write  command. 
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where  n  =  LARGESTREAD  from  shared.h 

Figure  4. 1     Shared  Memory  Segment  Data  Assignment 

a  long  (4-byte)  integer.  Table  4.3  describes  the  meaning  of  three-state  values  placed  in 
this  area. 

Table  4.3     SHARED  MEMORY  MESSAGES 


Value 

Meaning 

to 

send 

Meaning 

to 
receive 

Meaning 

to 

Application 

positive 

Data  of  length  given  is 
in      shared      memory, 
ready  to  be  sent. 

Application     has     not 
finished    reading     data 
from  shared  memory. 

send:  Data  in  shared  memory 
has  not  yet  been  sent  to  other 
machine. 

receive:  Valid  data  of  length 
given  is  in  shared  memory, 
ready  to  be  read. 

zero 

Nothing    ready    to    be 
sent. 

Application     has     read 
data        from        sliared 
memory.            Message 
from  other  machine  can 
be    read,   up   to   LAR- 
GESTREAD bytes. 

send:  Previous  message  has 
been    sent.     Ready    to    send 
next  message. 

receive:    No    valid    data    in 
shared  memory. 

negative 

Signal  to  terminate. 

Signal  to  terminate. 

N/A 
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The  system  calls  supporting  shared  memory  are  shmget,  shmat,  shmdt,  and 
shmctl  [Ref.  25:  pp.  192-198].  To  simplify  their  use,  they  are  repackaged  into  four  high 
level  routines:  sharedsegment,  dynamicsharedsegment,  detachsharedsegment,  and 
deletesharedsegment.  These  routines  (and  a  support  routine  attach _within_datasegment) 
are  encapsulated  in  shareseg.c.  It  can  be  separately  linked  with  any  application  that 
needs  shared  memory.  Table  4.4  describes  the  four  routines. 

The  implementation  of  shared  memory  on  the  IRIS  2400  and  IRIS  3120 
was  a  surprise.  A  basic  UNIX  memory  allocation  scheme  is  shown  in  Figure  4.2.  Each 
process  has  its  own  text,  data,  and  stack  sections.  Neither  the  relative  locations  of  these 
sections  nor  the  direction  of  growth  for  stack  and  data  sections  is  specified  for  UNIX. 
The  shared  memory  segments  are  logically  part  of  the  data  section  [Ref.  26:  p.  151]. 
Table  4.4     SHARED  MEMORY  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

sharedsegment 

Creates  (if  not  already  in  ex- 
istence)   a    shared    memory 
segment    associated    with    a 
key.    Attaches  application  to 
that  shared  memory  segment. 
Returns    a    shared    memory 
segment     address     and     id 
Does  not  permit  subsequent 
dynamic  memory  allocation. 

char  *sharedsegment(  key,  nbytes,  shmid  ) 

long  key; 

long  nbytes; 

int  *  shmid; 

segment  =  sharedsegment(  key,  nbytes,  shmid  ) 

dynamicsharedsegment 

Creates  (if  not  already  in  ex- 
istence)   a    shared    memory 
segment    associated    with    a 
key.    Attaches  application  to 
that  shared  memory  segment. 
Returns    a    shared    memory 
segment  address  and  id.  Per- 
mits     subsequent      dynamic 
memory  allocation. 

char  *dynamicsharedsegment(  nummachines, 

key,  nbytes,  shmid,  freespace  ) 
int  nummachines; 
long  key; 
long  nbytes; 
int  *  shmid; 
int  freespace; 

segment   =  dynamicsharedsegment(          num- 
machines, key,  nbytes,  shmid,  freespace  ) 

detachsharedsegment 

Detach  shared  memory  seg- 
ment from  application 

void  detachsharedsegment(  segment  ) 
char  *  segment; 

deletesharedsegment 

Delete    shared   memory   seg- 
ment 

void  deletesharedsegment(  segment,  shmid  ) 
char  *segment; 
int  shmid; 
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Figure  4.2     UNIX  Memory  Allocation 


Actual  implementation  is  left  to  the  team  porting  UNIX  to  the  machine.  The  Silicon 
Graphics,  Inc.  implementation  attaches  a  shared  memory  segment  to  the  first  available 
valid14  address  within  the  data  section.  However,  the  beginning  of  shared  memory 
delimits  the  size  of  all  other  sections  [Ref.  26:  pp.  367-370].    Figure  4.3  illustrates  this 


14  Shared  memory  segments  must  begin  on  a  page  boundary.   This  allows  easy  table-driven  access  by  multiple 
processes.   On  the  IRIS  2400  and  3120  machines,  the  Motorola  68000  architecture  is  used.  The  pages  are  8KBytes. 
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Figure  4.3     IRIS  2400  Default  Shared  Memory  Attachment 


1  S 

relationship.  While  no  dynamic  memory  calls  are  made,  the  default  arrangement  works 
fine.  But  when  dynamic  memory  allocation— linked  lists  and  makeobjO  calls  are 
examples — is  needed,  the  technique  fails. 

To  allow  dynamic  memory  allocation,  the  shared  memory  segment  must 
be  attached  at  an  address  beyond  the  greatest  ever  required  for  regular  data.  Dynamic 
allocation  can  then  occur  without  reaching  the  shared  memory  segment.  Attaching  at  an 
unknown  address  both  within  the  data  section  and  sufficiently  beyond  existing  data  to 
permit  dynamic  data  section  growth,  can  be  done  at  least  two  ways.  First,  the  data 
section  can  be  expanded  until  it  is  as  large  as  possible,  then  the  shared  memory  segment 


15  Dynamic  memory  allocation  is  made  with  system  call  brk  or  alternate  sbrk.  Library  functions  nialloc,  realloc, 
and  calloc  use  brk  and  so  also  do  dynamic  memory  allocation. 
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can  be  attached  at  a  valid  location  just  inside  this  maximum  value.  While  minimizing 
application  programmer  effort,  this  technique  requires  many  system  calls  to  grow  the 
data  section.  It  also  has  the  fatal  flaw  of  limiting  the  stack  section,  if  the  stack  section 
and  data  section  grow  into  the  same  unallocated  memory.  Second,  the  application  can  be 
required  to  prespecify  the  maximum  amount  of  dynamic  memory  allocation  it  might  use. 

The  solution  adopted  is  adding  a  freespace  parameter  to  the 
sharedsegment  function;  and  renaming  it  the  dynamicsharedsegment  function.  The 
sharedsegment  function  was  retained  for  backward  compatibility.  The  freespace 
parameter  gives  the  caller  the  ability  to  specify  the  maximum  additional  memory 
required  for  the  application.  A  request  for  this  additional  space  is  made  before  the  shared 
memory  segment  is  attached.  After  acquiring  (and  freeing)  the  additional  space,  the  next 
available  address  is  determined  and  the  shared  memory  segment  is  attached  to  the  next 
valid  address.  We  have  now  established  the  shared  memory  segment  beyond  the 
specified  growth  of  the  application's  data. 

When  multiple  machines  are  connected  together,  there  must  be  a  separate 
shared  memory  buffer  for  each  channel.  There  is  no  way  to  connect  a  second  shared 
memory  segment.  The  solution  adopted  is  adding  a  num  mac  nines  parameter  to  the 
dynamicsharedsegment  function.  The  nummachines  parameter  requires  the  application 
developer  to  specify,  in  advance,  the  maximum  number  of  channels  that  can  be  created  in 
the  application.  The  first  dynamicsharedsegment  call  establishes  a  shared  memory 
segment  big  enough  for  nummachines  maximum  requested  channels.  Subsequent 
dynamicsharedsegment  calls  return  the  same  shared  memory  id  as  the  first;  but  return  a 
different  address  within  the  segment.  Since  the  application  does  not  directly  access  these 
functions,  there  were  no  problems  caused  by  this  parameter  list  change. 
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The  shared  memory  functions  are  isolated  from  the  application  by  the 
machinepath,    dynamicmachinepath,    dynamicmachinepaths ,    and    deletemachinepath 

functions16.  For  the  direct  connect  protocol,  each  machinepath,  dynamicmachinepath,  or 
dynamicmachinepaths  call  spawns  both  a  send  and  a  receive  process.  For  the  broadcast 
protocol,  these  calls  spawn  only  a  send  process  (for  the  broadcaster)  or  a  receive  process 
(for  the  receiver).  In  all  cases,  the  spawned  processes  issue  a  sharedsegment  call  to 
attach  to  the  shared  segment  earlier  created  by  the  spawning  function.  A  command  line 
parameter  is  passed  providing  the  offset  into  the  shared  memory  segment  that  the 
spawned  process  is  to  use.  Figure  4.4  illustrates  a  system  with  three  machines  and  two 
channels. 

d.      Buffering 

(1)  Direct  Connect.  When  a  receive  process  is  quiescent,  waiting  for 
the  application  to  read  from  the  shared  memory  buffer,  anything  sent  to  it  is  buffered  by 
TCP/IP.  The  buffering  provides  the  reliable  delivery  promised  by  a  stream  socket.  The 
next  read  command  will  deliver  up  to  LARGESTREAD  bytes  into  the  receive  data  area  of 
the  shared  memory  buffer.   Since  the  messages  are  variable  length,  there  cannot  be  a 

guarantee  that  only  one  message  was  read17.  Multiple  messages  might  be  in  the  shared 
memory  buffer.  A  partial  message  might  be  in  the  last  bytes. 

The  shared  memory  buffer  management  is  handled  by  the  various 
read  functions18  provided.  Each  read,  requested  by  the  application,  is  satisfied  from  the 


16  See  Chapter  5,  Sections  A.l.b(l)  and  A.l.b(3)  for  more  information  on  these  functions. 

17  The  idea  to  pad  all  messages  to  some  arbitrary  size  was  considered  and  rejected.  Whatever  size  was  chosen 
would  always  be  too  small  for  some  character  array.  If  the  maximum  Ethernet  packet  size  was  chosen,  an  unnecessary 
network  dependence  would  be  introduced.  The  cost  of  application  buffer  management  is  considered  acceptable,  espe- 
cially since  it  is  incurred  only  on  reads. 

See  Chapter  5,  Section  A.  l.b(2)  for  more  information  on  these  functions 
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Figure  4.4     Three-Machine  Interconnection 
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shared  memory  buffer.  Remaining  valid  data  is  shifted  into  the  low  order  positions  of  the 
data  area.  The  count  of  valid  bytes,  held  in  the  message  area,  is  decremented.  The 
shared  memory  buffer  now  appears  as  it  would  have,  if  it  had  only  received  the 
remaining  data  and  not  the  first  message  at  all.  As  long  as  only  entire  messages  are 
received  (one  or  more  at  a  time),  this  works  well.  When  the  TCP/IP  buffer  has  more  data 
than  the  data  area  can  take  at  one  time,  however,  the  receive  process  deposits 
LARGESTREAD  bytes  in  the  shared  memory  data  area.  It  is  highly  unlikely  that  this  will 
be  on  a  message  boundary. 

A  socket  read  overwrites  all  data  in  the  data  area.  A  partial  data 
reception  must  be  stored  and  concatenated  with  bytes  from  the  next  socket  read  to  get  a 
complete    message.     The    protocol    area    was    introduced    to    retain    the    protocol 

information19  required  to  decipher  the  variable  length  messages.  The  count  of  already 
received  bytes  of  a  message  is  held  here  between  socket  reads.  A  message's  protocol 
information  is  stored  here,  too.  Protocol  information  is  built  up  until  complete  (covering 
the  possibility  that  the  break  is  in  the  protocol  information  itself).  It  is  then  maintained 
until  the  entire  message  is  received  and  read  by  the  application.  The  buffering  works 
with  data  areas  as  small  as  four  bytes20. 

(2)  Broadcast.  The  datagram  socket  used  by  the  broadcast  protocol 
preserves  message  boundaries.  Each  recvfrom  call  to  a  socket  returns  only  one  message. 
This  message  must  be  no  longer  than  LARGESTREAD  bytes.  The  shared  memory  buffer 
management  routines  are  not  needed. 


19 


See  Chapter  3,  Section  B.  1  for  a  description  of  the  protocol 


20  LARGESTREAD  must  be  specified  in  multiples  of  four  bytes.  The  smallest  possible  data  area  is  therefore 
four  bytes. 
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TCP/IP  keeps  unread  messages  on  a  queue.  This  queue  may  not  be  in 
sending  sequence.  If  the  queue  buffer  becomes  full,  subsequent  messages  are  lost 
[Ref.  21:  p.  8-8].  The  sending  buffer  can  easily  be  filled  if  many  messages  are  broadcast 
in  a  short  period  of  time.  Each  broadcast  message  must  be  processed  by  every  host  on 
the  Ethernet.  Only  then  can  the  next  be  sent.  No  access  for  manipulation  of  the  TCP/IP 
sending  buffer  is  provided  because  its  size  is  normally  specified  during  system  generation 
and  is  not  easily  manipulated  by  an  application  program. 

2.  Silicon  Graphics,  Inc.  IRIS  3120 

There  are  no  required  changes  to  the  IRIS  2400-Turbo  code.  The  Makefile 
must  be  changed  to  remove  the  -Zf  compile  flag,  since  there  is  no  floating  point 
accelerator  board  in  this  machine. 

3.  Silicon  Graphics,  Inc.  IRIS  4D 

The  IRIS  4D  required  programming  changes  only  to  the  shared  memory 
module,  shareseg.c.  The  path  name  for  user  directories  is  also  different.  Changes  were 
necessary  to  the  Makefile  because  the  lusrlinclude  directory  structure  changed. 

The  IRIS  4D  is  based  on  the  MIPS  RISC  architecture.  The  UNIX 
implementation  was  done  differently  than  that  for  the  Motorola  68020.  Shared  memory 
segments  are  not  attached  to  addresses  within  the  data  section,  as  illustrated  in  Figure 
4.5.  They  are  attached  at  a  much  higher  address,  yet  accessing  them  does  not  result  in  a 
segmentation  violation.  This  is  a  more  robust  technique  that  obviates  any  manipulation 
of  attachment  addresses.  Multiple  shared  memory  segments  are  easily  attached,  using 
default  system  calls.  The  sharedsegment  call  suffices,  even  when  dynamic  memory 
allocation  is  needed.  To  maintain  backward  compatibility  for  application  code, 
dynamicsharedsegment  calls  sharedsegment,  ignoring  the  freespace  parameter,  when 
compiled  on  an  IRIS  4D,  and  calls  attach _within_datasegment  when  compiled  on  an 
older  IRIS  machine. 

33 


Shared  Memory  Sezaen 


.M     mmt 


Unallocated 

Available 

Memory 


Data  Section 


Code  Section 


Maximum 

Data 
Section 
Address 


Unallocated 

Available 

Memory 


Data  Section 


Code  Section 


Before 


After 


Figure  4.5     IRIS  4D  Default  Shared  Memory  Attachment 


C.     4.3BSDUNDC 

The  netV.c  file  functions  properly  on  a  4.3BSD  machine  that  is  connected  to  only 
one  network.  The  start  ^broadcast  function  does  not  properly  handle  multiple  networks. 
The  other  functions  work  correctly,  even  when  the  machine  is  connected  to  multiple 
networks. 

All  other  functions  depend  upon  semaphores  and  shared  memory  for 
communication   between   the   spawned  processes   and  the   main   application.    Stream 

sockets21  could  be  used  to  provide  the  IPC  between  these  processes  under  4.3BSD.  The 


21  Unidirectional  stream  sockets  are  equivalent  to  pipes. 
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three  channels     used  will  have  to  be  multiplexed  into  one,  but  the  implementation  is 
otherwise  straightforward. 

D.    Lisp  Machines 

The  communication  code  is  a  flavor  to  be  mixed  with  the  application  [Ref.  11].  The 
Explorer  software  is  syntactically  equivalent  to  Genera  6  on  the  Symbolics.  With  a 
simple  change  in  the  sequence  of  method  and  flavor  names,  the  Genera  7  code  runs  on 
the  TI  Explorer.  The  older  flavor,  originally  developed  for  the  Explorer,  is  also  presented 
to  illustrate  working  directly  with  TCP/IP  instead  of  using  a  stream. 

1.      Texas  Instruments  Explorer  I 

This  older  flavor  works  with  Release  1.0  of  the  Explorer  TCP/IP  software.  It 
will  not  work  with  Release  2.0  as  the  implementation  was  changed  from  blocking  to 
non-blocking  [Ref.  27]. 

Messages  to  the  flavors  in  the  ip  package  are  made  together  with  messages  to 
the  tcp  flavors.  Network-independent  addressing  is  not  used.  Table  4.5  describes  the 
addressing  schemes  possible  [Ref.  28:  pp.  4-2 — 4-3].  Class  C  addressing  is  used  by  the 
Computer  Science  Department.  Figure  4.6  shows  the  simple  encapsulation  of  the 
addresses  for  irisl,  iris2,  and  iris3.  Extension  to  include  other  machines  is  easy. 

Table  4.5     INTERNET  ADDRESSING  CLASSES 


Class 

No. 
Networks 

No. 
Hosts 

A 

128 

16,777,216 

B 

16,384 

65,536 

C 

2,097,152 

256 

22  These  are  the  semaphore,  the  message  areas  of  the  shared  memory  buffer,  and  the  data  areas  of  the  shared 
memory  buffer.  The  first  is  unidirectional  from  application  to  spawned  process.  The  second  is  bidirectional  and  three 
state  (see  Table  4.3). 
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(defvar  * i r i s  1  -  addres s*  3221866502) 
(defvar  * i r i s2 - addre s s*  3221866504) 
(defvar  * i r i s 3  - addres s *  3221866505) 

(defvar  *des t -  address*   nil)  ;  the  tcp-ip  or  internet  address 

;  look  in  network  configuration 

( def un  iris  ( x) 

(cond  ((equal  x  1)  (setq  *des t - addres s*  * i r i s 1  - addres s* ) ) 

((equal  x  3)  (setq  *des t -addres s*  * i r i s3- addres s* ) ) 

(t  (setq  *des t -addres s*  *i r i s2- addres s* ) )  )  ) 

Figure  4.6     Encapsulation  of  IRIS  Addresses 


A  port  is  acquired  by  using  the  : get-port  method  of  the  tcp-handler  flavor. 
Here,  shown  in  Figure  4.7,  we  use  the  global  instance,  *tcp-handler*23  to  create  specific 
instances  of  the  Transmission  Control  Block  (TCB)  for  each  of  the  two  ports.  Only  the 
client  side  of  the  server/client  paradigm  has  been  implemented.  The  client  is  created  by 
using  the  :active  mode  argument  to  the  : open  method  of  the  tcp-port  flavor.  Both  the 
sending  and  receiving  ports  are  full  duplex,  but  are  only  used  in  a  simplex  mode.  Figure 
4.8  shows  the  creation  of  the  sending  port  [Ref,  28:  pp.  4-12 — 4-18]. 

The  three  fields  in  a  message  are  sent  and  received  separately.  Each  field  is 
then  treated  as  a  separate  object.  Figure  4.9  illustrates  sending  a  message.  For  all  fields, 
the  urgent  argument  is  specified  as  nil.  The  push  argument  is  specified  as  nil  until  the 


(defvar  * t cp- hand  I e r 1  *  (send  ip  ::* t cp- handl e r*  :get-port)) 
(defvar  * t cp -  hand  1 e r2*  (send  ip ::* t cp- handl e r*  :get-port)) 

Figure  4.7     Lisp  Port  Acquisition 


The  double  :  allows  the  tcp-handler  to  be  found,  since  it  was  not  created  "exportable"  in  the  ip  package. 
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(send  talking-port  :open 
: ac  t  i  ve 

talking-port- numbe  r 
destination 


30  ) 


tcp  will  begin  the  procedure  to  establish 
connection   (default   vs  :  p  a  s  s  i  v  e  ) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  :passive  mode  local  machine  waits  for 
connec  t  ion 
set  max  seconds  before  read  request  times  out 


Figure  4.8     Opening  a  Lisp  Client  Connection 


(progn 
(s 


(i 


(s 


end  talking-port  : send 
typebuf f e  r 
1 

nil 
nil  ) 
f  (=  (length  lengthbuf fer)  4) 
(send  talking-port  : send 
1 eng  t  hbuf f er 
4 

nil 
nil  ) 
(progn 

(loopfor  *loopvari able*  (length  1 eng t hbuf fer )  4 
(send  talking-port  : send  "0"  1  nil  nil)  ) 
(send  talking-port  : send  lengthbuffer  (length  leng thbuf f er )  nil  nil)  )  ) 
end  talking-port  : send 
buffer 

buf f e  r - 1 eng t h 
t 
nil  )  ) 

Figure  4.9     Sending  a  Message 


data  buffer  is  sent,  when  it  is  specified  as  t.  The  entire  message  is  thus  sent  as  a  unit  to 
the  other  machine. 

2.      Symbolics  36xx 

Genera  7  syntactic  conventions  are  followed.  The  principle  difference  with 
Genera  6  conventions  is  in  the  deftnethod  function.  In  Genera  6  (and  the  TI  Explorer), 
the  method  name  follows  the  flavor  name,   hi  Genera  7,  the  method  name  precedes  the 
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flavor  name.  Figure  4.10  shows  the  difference.  It  also  shows  the  other  main  difference 
with  the  earlier  code,  that  streams  are  used.  The  use  of  streams  improves  portability  and 
eliminates  the  need  for  the  :reuse-iris  method  .  It  may  be  slightly  slower,  but  any 
difference  has  been  unnoticeable. 

Another  change  was  to  remove  the  dependence  on  hard-coded  addresses.  The 
method  :init-destination-host  was  added  to  the  conversation-with-iris  flavor  (see 
Figure  4.11).  By  using  the  net: parse-host  function,  the  application  need  only  know  the 
name  of  another  machine.  As  network  tables  are  updated,  no  change  to  the  application 
code  is  necessary  unless  a  different  machine  is  desired. 


(defmethod  ( conve r sa t ion-wi  th- i r i s  :stop-iris) 
() 

(progn  (send  talking-port  :close) 
(send  listening-port  :close)  )  ) 

Genera  6 

(defmethod  (:stop-iris  conversa t i on-wi  th- i r i s ) 

() 

(progn  (send  t a  Iking- s t ream  :close) 
(send  1 i s t en ing- s t ream  :close)  )  ) 

Genera  7 
Figure  4.10     Genera  6  and  7  defmethod 


(defmethod  (  : i ni t -des t ina t i on-hos t  conver sa t ion-wi  t h- i r i s ) 
( n  ame  -of- host ) 
(setf  de s t i na t ion-hos t -obj ec t  (ne t  : par se - hos t  name  -  of  - hos t  )  )  ) 

Figure  4.11     Generic  Host  Addressing 


'  The  :reuse-iris  method  is  retained  for  backward  compatibility. 
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E.     Summary 

For  UNIX-based  machines,  generic  routines  are  developed  for  semaphore  use, 
shared  memory  use,  and  socket  use.  The  socket  routines  use  both  stream  sockets  and 
datagram  sockets  in  a  simplex  mode  to  provide  directly  connected  client/servers  and 
unconnected  broadcasting  communications.  IRIS  2400,  3120,  and  4D  systems  are  fully 
supported.  4.3BSD  systems  are  supported  with  mid-level  socket  calls  only. 

For  Lisp  machines,  stream-based  functions  are  available  for  direct  connection  as 
clients  only.  These  functions  are  available  directly  if  using  Genera  7  syntax  and  with 
minor  modification  if  using  Genera  6  syntax. 
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V.  Use  by  Applications 

A.    Introduction 

The  application  using  either  direct  connect  or  broadcast  protocol  is  not  concerned 
with  system-level  implementation  details.  Almost  all  aspects  of  shared  memory, 
semaphore,  and  socket  use  are  hidden.  The  number  of  other  machines  to  be  connected 
to,  the  use  of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  all 
that  concern  the  application  in  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision,  not  a  protocol 
decision. 

B.      DIRECT  CONNECT 

A  UNIX-based  machine  can  be  either  a  server,  waiting  for  a  client  to  call  and 
establish  a  connection,  or  the  client.  A  Lisp  machine  is  always  a  client. 

1.      UNIX-Based  Machines 

The  functions  provided  for  UNIX-based  machines  are  all  written  in  C.  They 
must  be  linked  into  the  application  program  using  them.  Figure  5.1  is  an  example  make 
file  for  creation  of  an  application  program  on  an  IRIS  system. 

There  are  two  independent  processes,   send  and  receive,  that  are  spawned  to 

create  the  sockets  and  monitor  them.    They  are  made  separately  with  the    makefile25 
contained  in  their  subdirectory. 


See  Appendix  A 
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CFLAGS  =  -Zg  -  lm  -g  -p 

SHARE  =  /work/bar  row/ share3/ 

MAIN  =   carsimu.c 

OBJS    =      First  group  of  .o  files 

OB  J  S 1    =  Second  group  of  o  files 

OBJS2    =   Third  group  of  o  files 

OBJS3  =  $( SHARE) io_single.o  \ 
$(SHARE)mpath.o  \ 
$(SHARE) semaphore . o  \ 
$(SHARE)shareseg.o  \ 
$( SHARE ) suppor t .o 

OBJS4    =  Fifth  group  of  .o files 

carsimu:  $(MAIN)  $(OBJS)  $(OBJSl)  $(OBJS2)  $(OBJS3)  $(OBJS4) 

cc  -o  carsimu  $(MAIN)  $(OBJS)  $(OBJSl)  $(OBJS2)  $(OBJS3)  $(OBJS4)  $(CFLAGS)  -lbsd 

$(MAIN):  const. h  vars.h 

$(OBJS):  const. h  vars.h 

$(OBJSl):  const. h  objects. h 

$(OBJS2):  const.h 

$(SHARE)mpath.o:  $(SHARE) shared . h 

cc  -c  -o  $(SHARE)mpath.o  $(SHARE)mpa t h . c  $(CFLAGS) 

$(SHARE) support .o:  $ (SHARE) shared . h 

cc  -c  -o  $(SHARE) suppor t .o  $(SHARE) suppor t . c  $(CFLAGS) 

$( SHARE) semaphore . o : 

cc  -c  -o  $(SHARE) semaphore .o  $(SHARE) semaphore . c  $(CFLAGS) 

$(SHARE) io_single. o:  $(SHARE) shared . h 

cc  -c  -o  $(SHARE)io_single.o  $(SHARE) i o_s ingl e . c  $(CFLAGS) 

$(SHARE)shareseg. o: 

cc  -c  -o  $(SHARE)shareseg.o  $(SHARE) share seg . c  $(CFLAGS) 

Figure  5.1     Sample  Application  make  File 


a.      Application  Setup 

The  server  process  must  be  started  first.   The  application  can  set  up  the 
communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response  to  a 
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specific  operator  command.  In  either  case,  there  will  be  two  messages  returned  to  the 
terminal  for  each  direct  connection  setup.  Figure  5.2  illustrates  a  normal,  single 
connection,  response.  Since  the  receive  and  send  processes  that  provide  the  messages 
are  independent,  the  two  lines  shown  may  be  jumbled.  A  variety  of  errors  can  occur  at 
this  point.  Table  5.1  gives  the  most  common  error  messages,  their  cause,  and  solution. 


Server  waiting    to   connect    to  name 
Server  waiting    to   connect    to   name 


Figure  5.2     Normal  Server  Response 


Table  5 . 1     SERVER  ERROR  RESPONSES 


Message 

Cause 

Solution 

Server  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

Server  couldn't  bind  address  to  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

shmget:  Permission  denied 

The   shared  memory   seg- 
ment already  exists,  but  is 
owned  by  another  uid 

Change            key            in 
machinepath   call,    recom- 
pile, and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg- 
ment already  exists,  but  is 
too  small  because  the  value 
of    LARGESTREAD    has 
been  increased 

Run  rmshare  and  rerun  ap- 
plication 

shmat:  Permission  denied 

Someone  else's  send  or  re- 
ceive    process     is     being 
spawned 

Outdated  software  is  being 
used. 

Gieck  that  proper  path  is 
used      in      shared.  It,      for 
application's     include     of 
shared.lt,           and           in 
application's          Makefile. 
Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.    If  some 
are      not,       get      updated 
modules   and  recompile — 
especially     send    and    re- 
ceive. 

42 


The  client  process  must  not  attempt  connection  until  after  the  server  is 
properly  running  (the  messages  in  Figure  5.2  have  been  received).  The  application  can 
set  up  the  communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response 
to  a  specific  operator  command.  When  client  communications  setup  is  part  of  the 
initialization,  care  must  be  taken  to  wait  for  a  ready  server  before  starting  the  client.  In 
either  case,  there  will  be  two  messages  returned  to  the  terminal  for  each  direct 
connection  setup.  Figure  5.3  illustrates  a  normal,  single  connection,  response.  Since  the 
receive  and  send  processes  that  provide  the  messages  are  independent,  the  two  lines 
shown  may  be  jumbled.  A  variety  of  errors  can  occur  at  this  point.  Table  5.2  gives  the 
most  common  error  messages,  their  cause,  and  solution, 
b.      Coding  Practices 

(1)  Connection.  Making  a  connection  requires  two  acts.  The  first  is  to 
set  aside  space  for  the  data  required.  Figure  5.4  shows  this  code  when  local  declaration 
is  used.  The  Machine  structure  can  also  be  declared  globally.  The  second  is  to  request 
the  connection  with  a  machinepath,  dynamicmachinepath,  or  dynamicmachinepaths 
call.  Table  5.3  compares  the  three  types  of  call,  while  Figure  5.5  gives  a  server  example 
for  dynamicmachinepath.  A  description  of  the  parameters  used  is  in  Appendix  A, 
Section  2. a. 

For   flexibility,   there    is   often   a  requirement   for   command   line 
specification  of  the  machine  to  be  connected  to.    For  ease  of  use,  there  is  often  a 


Connection    established  with   name 
Connection    established  with   name 


Figure  5.3     Normal  Client  Response 
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Table  5.2     CLIENT  ERROR  RESPONSES 


Message 

Cause 

Solution 

Client  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

Client  couldn't  connect  to  the  remote  server  socket: 

The  server  has  not  success- 
fully started 

The  port  numbers  used  by 
client  do  not  correspond  to 
those  of  server 

Terminate     client,     restart 
server,  restart  client  when 
server  started 

Correct,     recompile,     and 
rerun 

shmget:  Permission  denied 

The   shared  memory   seg- 
ment already  exists,  but  is 
owned  by  another  uid 

Change             key             in 
machinepath  call,   recom- 
pile, and  rerun 

shmget:  Invalid  argument 

The   shared  memory   seg- 
ment already  exists,  but  is 
too  small  because  the  value 
of    LARGESTREAD    has 
been  increased 

Run  rmshare  and  rerun  ap- 
plication 

slunat:  Permission  denied 

Someone  else's  send  or  re- 
ceive    process     is     being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used     in      shared,  ft,      for 
application's     include     of 
shared,  ft,           and           in 
application's         Makefile. 
Correct  and  recompile. 
Ensure  that  all  modules  are 
the  most  current.   If  some 
are      not,      get      updated 
modules  and  recompile — 
especially    send    and    re- 
ceive. 

#include  " /work/barrow/  share3/ shared. h" 

ma  in( argc , argv ) 

/************************************************************* 


LOCAL 


DECLARATIONS 


************************************************************* 


Ma  chine  cardriver 


/*  structure  for  conmun i ca t i ons  system  */ 


Figure  5.4     Creation  of  Machine  Structure 
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Table  5.3     PATH  CONNECTION 


Function 

Purpose 

machinepath 

Creates  a  link  between  two  machines 
No  subsequent  dynamic  memory  allocation  al- 
lowed 

dynamicmachinepath 

Creates  a  link  between  two  machines 
Subsequent  dynamic  memory  allocation  allowed 

dynamicmachinepaths 

Creates  a  link  between  two  machines 
Subsequent  dynamic  memory  allocation  allowed 
Multiple  calls  provide  multiple  links  to  one  or 
more  other  machines 

ma  i  n( argc , argv ) 

/♦a*********************************************************** 


SYSTEM 


INITIALIZATIONS 


***********  +  ******  +  ****  +  **********  +  ****-(.***********  +  ***  +  *♦*** 


/*  Open  up  the  net  path  to  other  machine  (iris3  default)  */ 
dynamicmach  inepath(2, other_machine ,4, 5, "server" ,&cardriver, 2000000) 

Figure  5.5     Server  Creation 


requirement  for  a  default  specification.  Figure  5.6  illustrates  one  way  to  accomplish  this 
for  a  client.  This  example  does  not  require  that  the  network  alias  be  defined  to  the 
system  as  it  uses  the  complete  address.  The  user,  however,  only  enters  the  alias. 

(2)  Program  Use.  The  simplest  high-level  communication  paradigm  is 
reading  from  and  writing  to  the  other  machine.  It  closely  parallels  handling  files  and 
terminals  in  C.  It  was  chosen  for  these  reasons. 

Twelve  high-level  functions  are  available.  Four  provide  status 
information,  four  write  to  other  jnachine,  and  four  read  from  other  jnachine .  Table  5.4 
describes  these  functions.  The  parameters  used  by  these  calls  are  described  in  Appendix 
A,  Sections  l.a  and  9. a. 
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main( argc , argv ) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 

I 

/************************************************************* 

DATA         DECLARATION 

***************************** ********************************  i 

char  o ther_machine [50] ;  /*  name  of  other  machine  */ 

/***  +  +  *****  +  *********** ******************  ********************* 

SYSTEM       INITIALIZATIONS 

******  *******************************  ************************! 

/*    pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2 ) 

( 

printf("NAV:  incorrect  argument  count!   use  nav  <alias>\n"); 
e  x  i  t  (  1 )  ; 

} 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

i  f (  argc  ==  2  ) 

{ 

strcpy(  ot her_machine ,  "npscs-"  ); 

strcat(  o t he r_machine ,  argv[l]  ); 

) 
else 

strcpy(  ot her_machine ,  "npscs - i r i s2"  ); 

/*  Open  up  the  net  path  to  other  machine  (iris2  default)  */ 
dynamicmachinepa  th(2 , o ther_machine ,5, 4, "client"  ,&car , 2000000) ; 

Figure  5.6     Command  Line  Direction  for  Connection 


There  is  a  variety  of  ways  to  use  these  functions.  Figure  5.7 
illustrates  a  typical  scenario.  This  code  is  from  the  display  station  of  a  two-workstation 
driver  simulation.  The  display  station  provides  its  status  (that  of  the  "world")  on  each 
pass  through  its  graphical  display  loop.  The  control  station  must  read  that  status  on  each 
pass,  to  update  the  vehicle  position  on  its  track  diagram.  On  each  pass,  the  display 
station  checks  to  see  if  any  commands  have  been  received.  This  is  an  asynchronous 
communication,   as   the  display   station  continues  with  or  without  a  control  station 
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command.  The  asynchronous  reads  are  guarded  by  a  receiver _has_data  call  that  detects 
arrival  of  a  message.  Other  receiver  _has_data  calls  are  used  to  "busy  wait"  for  the  next 
message.  In  practice,  it  has  not  been  necessary  to  include  any  but  the  first  "busy  wait" 
receiver _has_data  call.  TCP/IP  buffers  messages  when  they  are  not  immediately  read. 
It  then  blocks  them  into  the  largest  grouping  possible  and  delivers  them  when  the  next 
read  occurs.  The  LARGESTREAD  denned  constant  in  shared. h  determines  this 
maximum  grouping.  The  first  message  is  read  by  receive.  The  socket  is  then  ignored 
until  the  application  reads  the  data.  During  this  time,  the  other  messages  have  all  been 
sent  and  buffered  by  TCP/IP.  There  is  a  slight  delay  between  the  time  the  first  message  is 
read  and  the  block  containing  all  the  rest  is  read.  Thus  the  necessity  for  the  first  "busy 
wait"  receiver _has _data  call.  The  other  "busy  wait"  receiver _has_data  calls  are  simply 
for  robustness. 

The  "busy  wait"  sender Js  Jree  call  determines  if  something  has 
happened  to  the  other  machine  or  Ethernet.  The  first  write  will  always  succeed,  as  it  goes 
to  a  buffer.    If  there  is  a  communications  problem,  TCP/IP  will  not  accept  it  and  the 

Table  5.4     COMMUNICATION  FUNCTIONS 


Function 

Action 

sender_is_free 

receiver_has_data 

received_type 

number_received 

Returns  TRUE  if  a  message  can  be  sent. 

Returns  TRUE  if  a  new  message  has  been  received. 

Returns    a    character    indicating    the    type    of    the    message.     CHARACTER_TYPE, 

INTEGER_TYPE,    and   FLOATTYPE    are    predefined.     CHARACTER_ARRAY_TYPE, 

1MTEGER_ARRAY_TYPE,  and  FLOAT_AJRRAY_TYPE  are  predefined 

Returns  an  integer  indicating  how  many  elements  in  message. 

write_character 
write_integer 
write_float 
write_characters 

Send  a  single  value  of  the  type  to  other  machine. 

read_character 
read_integer 
read_float 
read_characters 

Move  single  value  of  named  type  from  buffer  to  application  program  storage. 

47 


ma  i  n( argc , argv ) 


************************************************************* 


MAIN 


SIMULATION 


LOOP 


****************************************+******+************+/ 

whi 1 e (vehi c 1 e . command . condi t ion  !=  DONE) 

( 

/************************************************************** 

Get  commands  (if  any)  from  navigator.   Comnands  are  all  sent 
or  none  are  sent  so  no  information  is  needed  as  to  which  value 

i  s  wh  i  c  h . 

*********************  **********  *******  ************************/ 

if(  rece i ver_has_da t a(  &cardriver  )  ) 


read_i  n t  ege r (&cardr  iver,  &veh  ic 1 e . command .condi tion); 

wh  i  1  e (  ! rece i ver_has_da t a(  &cardriver  )  )  / *pr i n t f ( "  1 " ) */ 

read_intege  r (&cardr iver,  &vehic le . command .brakepedal ) ; 

while(  ! rece i ver_has_da t a(  &cardriver  )  )  / *pr in t f ( "2" ) */ 

read_in t  eger (&cardr  i ver ,  &r  emot  e_mousex) ; 

while(  ! rece i ver_has_da t a(  &cardriver  )  )  /*pr in t f ( "3" )*/ 

read_floa  t  (&cardr  iver,  &cmd speed) ; 


I  *******  ******************************************************* 

Report  all  status  information  to  navigator  every  cycle. 

******************  ********************************************< 


wr  i  t  e_floa  t  (&cardr  i  ver  ,  &veh  icle.state_vector[l]) 

while(  ! sender_i s_f ree(&cardr i ver )  )  printf("b") 

wr  i  t  e_floa  t  (&cardr  iver,  &veh  icle.  state_vector[2]  ) 

wr  i  t  e_floa  t  (&cardr  i  ver  ,  &veh  icle.  state_vector[3]  ) 

wr  i  t  e_floa  t  (&cardr  i  ver  ,  &veh  icle.  si  tuat  ion.distance_traveled)  ; 

wri  te_integer (&cardr  iver,  &vehic 1 e . conmand .condi tion); 

wri  te_integer (&cardr  iver,  &vehi  c 1 e . command .brakepedal ) ; 

wri  te_integer (&cardr  i ver ,  &veh  icle. si  tuat  ion. 1 ightcolor) ; 


)  / *  wh  i 1 e  1 oop  *  / 


)   / *  ma  in  */ 


Figure  5.7     Synchronous  Write  /  Asynchronous  Read 
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sender  jsjree  call  will  return  FALSE.  This  often  occurs  when  there  is  a  delay  by  the 
client  in  connecting  to  the  server  (the  display  station  here).  If  there  is  a  good  connection, 
TCP/IP  will  accept  and  buffer  all  input.  No  other  "busy  wait"  calls  are  needed.  The  other 
side  of  the  communication  is  shown  in  Figure  5.8. 

(3)  Disconnection.  Tennination,  with  a  deletemachinepath  call  for 
each  path  opened,  is  mandatory.  If  not  performed,  the  sockets  (and  shared  memory 
segment  on  System  V  UNIX  machines)  will  not  be  returned  to  the  system.  Problems26 
may  then  occur  on  the  next  run.  Figure  5.9  is  an  example  termination  when  multiple 
paths  have  been  opened  [Ref.  11]. 
2.      Lisp  Machines 

All  necessary  functions  are  contained  in  a  single  file.  This  file  must  be  loaded 
before  use.  Figure  5.10  is  an  example.  A  Lisp  machine  is  always  a  client  and  is  started 
second.  Figure  5.11  illustrates  the  message  returned  with  a  successful  connection. 
Unsuccessful  connections  "hang"  and  return  nothing. 

a.      Connection 

The  address  of  the  server  and  the  ports  it  is  using  must  be  specified. 
Figure  5.12  shows  the  ports  specified  as  part  of  the  loaded  file.  When  using  the  older  TI 
Explorer  functions,  the  addresses  are  specified  in  the  same  way  (see  Figure  4.5)  and  then 
the  machine  desired  is  requested  by  number^  (shown  in  Figure  5.13).  When  using  the 
stream-based  functions,  the  addresses  are  not  specified  by  the  user  at  all.  The  network 
tables  are  accessed,  by  host  name,  through  the  select-host  function  provided  (shown  in 
Figure  5.14).   Once  the  instance  of  conversation-with-iris  flavor  has  been  completed 


26  See  Tables  5.1  and  5.2 

27  A  throwback  to  connection  only  with  different  IRIS  machines. 
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ma  in(argc.argv) 


wh  i 1 e (condi t ion  !=  DONE) 

I 

/♦*****+***+****  ******************************************* *  *  *  * 

Receive  all  status  information  from  car  every  cycle. 
**************************************************************/ 


wh  i  1  e 

(     ! 

rece  i ver_has_ 

.dat  a( 

fear    )     ) 

read_ 

fioa 

t  (&car  ,   &cy)  ; 

wh  i  1  e 

(     ! 

rece  iver_has_ 

data( 

fear    )     ) 

read_ 

fioa  t  (&car  ,    &cx  )  ; 

wh  i  1 « 

'(     ! 

rece  i ver_has_ 

dat  a( 

fe  a  r    )     ) 

read. 

fioa 

t(&car,    &velocity) 

• 

wh  i  1  e 

(     ! 

rece  i ver_has_ 

data( 

fear    )     ) 

read_ 

floa 

t  (fear  ,    &rdi  s 

t  ance 

); 

wh  i  1  e 

(     ! 

receiver_has_ 

data( 

fe  a  r    )     ) 

read_ 

int 

e  g  e  r  (&c  a  r  ,    &c 

ondi  t 

ion )  ; 

wh  i  1  e 

(     ! 

recei ver_has_ 

data( 

fear    )     ) 

read_ 

int 

eger  (fear  ,    &t 

r  akep 

as  i  t  i  on  )  ; 

wh  i  1  e 

(     ! 

receive  r_has_ 

data( 

fear    )     ) 

read_ 

.int 

eger  (fear  ,    &1 

i  gh  tcol or ) ; 

yT******************************************  **************  ****** 

Send  commands  (if  any)  to  car.   Commands  are  all  sent 

or  none  are  sent  so  no  information  is  needed  as  to  which  value 

i  s  wh  i  c  h . 

**************************************************************/ 

i  f ( any t hi ng_has_changed) 


any t hi ng_has_changed   =   FALSE; 
wr  i te_i n t eger (fear ,    feondition); 
while(     ! sender_i s_f ree(   fear    )    )    printf("a") 
wr  i  t  e_in  t  ege  r (fear ,    &brakepos  i  t  ion ) ; 
while(     !  sende r_i s_f ree (    fear    )     )    printf("b") 
wr  i  t  e_i  n  t  ege  r  (fear  ,    <Sonousex)  ; 

while(     ! sende r_i s_free(    fear    )     )    printf("c") 
wr  i  t  e_floa  t  (&c  ar  ,    femdve  loc  i  t  y  )  ; 
)       /*    i f ( any t h ing_has_changed )    */ 


)     / *    wh  i 1 e    * / 


)     I' 


Figure  5.8     Reciprocal  Synchronous  Read  /  Asynchronous  Write 
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de 1 e  t  emach  i  nepa  t h(&TI ) ; 
de  1  e  t  emachinepa  t  h  (&SW3  ) 
de  le  t  emach  i  n  e  p  a  t  h  (&S\M1  ) 
de  1  e  t  emach  i  nepa  t  h  (&S"YM4  ) 

exi  t  (  )  : 

Figure  5.9     Connection  Termination 


;;;     this    is    the    communication    package 
(load    "  i  r  i  sflavor  "  ) 


Figure  5.10     Loading  Lisp  Flavor 


'A  conversation  with  the  iris  machine  has  been  established' 

Figure  5.11     Lisp  Connection  Message 


(defvar  * i r i s 1 -por 1 1*  1027)  ;  this  is  the  send  port 

(defvar  * i r i s 1 -por t 2*  1026)  .  ;  this  is  the  receive  port 

Figure  5.12     Setting  Port  Numbers  with  defvar 


;;;  get  the  net  wo  r  k  going 

(iris  1 ) 

(setq  *battle*  (make  - i n s t ance  '  conver sa t i on-wi t h- i r i s ) ) 

(if  (y-or-n-p  "start  networking  ?")  (send  *  b  a  t  t  1  e  *  :  start-iris)) 

Figure  5.13     Specifying  Server  in  Lisp 
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(select- host     iris2) 

Figure  5.14     Specifying  Server  by  Name  in  Lisp 

with  port  numbers  and  host  addresses,  the  connection  is  established  with  the  method 
:start-iris,  see  Figure  5.13. 

b.  Program  Use 

The  method  :get-iris  returns  with  the  object  sent  by  one  message.  The 
method  (:put-iris  object)  sends  the  object  as  one  message.  Figure  5.15  illustrates  both. 
Note  how  methods  are  added  to  flavor  conversation-with-iris  to  simplify  the 
application  interf ace  even  further.  [Ref.   11] 

c.  Disconnection 

Disconnection  is  accomplished  with  the  method  :stop=iris,  shown  in 
Figure  5.16. 

C.      BROADCAST 

Only  UNIX-based  machines  support  our  broadcast  protocol  at  this  time.  It  is  a 
unidirectional  protocol,  but  nothing  prevents  the  establishment  of  two  unidirectional 
channels  in  opposite  directions.  Using  two  broadcast  channels  to  emulate  a  direct 
connect  channel,  however,  loads  all  other  machines  on  the  network  by  requiring  every 
other  machine  to  process  each  message.  It  is  also  less  reliable.  Broadcasting  is  good  for 
sending  status  information  to  many  other  machines,  as  long  as  those  machines  can 
tolerate  missing  reports. 

1.      Similarities  With  Direct  Connect  Protocol  Use 

Using  the  broadcast  protocol  is  similar  to  using  the  direct  connect  protocol. 
The  same  functions  are  used  in  the  same  way.   Each  connection  must  set  aside  space  as 
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defln  i  t  i  on  s 


obj  ec  t 


n 
x 

y 

z 

spd 

dir 


character  " 1 ' 


"5" 


x  coordinate:  real 

y  coordinate:  real 

z  coordinate:  real 

speed :  real 

direction:  real 


in  lisp   ("n"  (x  y  z  spd  dir)) 


speed  of  vehicle  -10.00  to  25.00 
compass  dir  in  degrees  from  GN 


;;;  get  an  object  in  graphics  environment  (defined  as  above) 

(defmethod  ( conver sa t i on -wi  t h- i r i s  :object) 
() 
(makeob j 

( send  self  :get-iris) 
get  - iri  s) 
ge  t - ir  i  s  ) 
get  -  iris  ) 
get  -  iris) 


( send  self 

( send  self 

( send  self 

( send  self 

( send  self 


get-iris)  )  ) 


;  ;  ;  vision  returns  a  list  of  objects  in  the  tank's  field  of  vision  (100m  radius) 
;;;  this  is  effectively  an  association  list 

(defmethod  ( conver sa t i on-wi  th- i r i s  :vision) 
( tank) 
(let  ((field  nil  ) 

(n-obj  ec  t  s  0)  ) 
(progn  (send  self  :put-iris  "V") 
(send  self  :put-iris  tank) 
(if  (equal  "V"  (send  self  :get-iris)) 

(progn  (setq  n-objects  (send  self  :get-iris)) 
(dot  imes 

(x   n-objects    field) 

(setq   field    (cons    (send    self     :object)    field))     )     )' 
(progn 

(print    "iris    did    not    respond    to    the    vision    corrmand    sent    from   ") 
(pr  inc    " t  ank    " ) 
(princ    tank)     )     )    )     )     ) 

Figure  5.15     Application  Communication  in  Lisp 


in  Figure  5.4.  The  same  criteria  for  using  a  specific  machinepath  call  apply  (see  Table 
5.3).  The  same  communications  functions  are  available  as  in  Table  5.4.  Each 
connection  must  be  terminated  as  in  Figure  5.9. 
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(if  (y-or-n-p  "stop  iris  connection  ?")  (send  *battle*  :stop-iris)) 

Figure  5.16     Termination  of  Communications  in  Lisp 


2.      Differences  With  Direct  Connect  Protocol  Use 
a.      Application  Setup 

The  broadcast  protocol  is  not  directly  modeled  as  a  server/client 
relationship.  The  broadcaster  broadcasts  to  whomever  is  prepared  to  receive.  The 
receiver  must  be  ready  and  so  must  be  started  first.  Since  the  broadcaster  is  more  similar 
to  the  server  in  a  server/client  model,  this  connection  order  seems  exactly  backward.  No 
error  will  result  if  the  broadcaster  starts  first,  messages  will  simply  not  be  received.  The 
receiver  message  is  shown  in  Figure  5.17.  The  broadcaster  message  is  shown  in  Figure 
5.18.  When  a  direct  connect  channel  is  also  required  between  the  same  two  machines, 
achieving  proper  startup  order  is  easy.  Establish  the  direct  connect  channel  first,  then  the 
soon-to-be  broadcasting  process  sends  a  message  telling  the  receiver  to  start  up.  Once 
started,  the  receiver  process  sends  a  message  permitting  the  broadcaster  to  start. 


ready    to   receive    from  broadcaster  name 

Figure  5.17     Normal  Receiver  Response 


Waiting  to  broadcast 

Figure  5.18     Normal  Broadcaster  Response 


54 


b.      Coding  Practices 

The  parameters  to  the  machinepath  family  of  functions  are  used 
differentiy  for  the  broadcast  protocol.  All  are  required  to  be  present,  but  some  are 
ignored  (see  Table  5.5).  Since  a  broadcast  channel  is  unidirectional,  the  receive  jype 
application  calls  are  meaningless  to  the  broadcaster  (the  receiver _has_data  call  always 
returns  false).  The  sendjype  application  calls  are  meaningless  to  the  receiver  (the 
sender  Jsjree  call  always  returns  false). 

D.     SUMMARY 

Using  the  same  functions,  an  application  can  either  broadcast  or  directly  connect  to 
another  machine.  The  same  steps  of  setup,  connection,  use,  and  termination  are  common 
to  both  protocols.  Care  must  be  taken  in  the  timing  of  the  two  (or  more)  machines  setup. 
After  that,  an  application  merely  reads  or  writes  data. 
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Table  5.5     MACHINEPATH  PARAMETERS 


Parameter 

Function 

machinepath          dynamicmachinepath 

dynamicmachinepaths 

nummachines 

N/A 

Number  of  channels  that  could 
be  created  by  application.  This 
includes    both   DIRECT   CON- 
NECT and  BROADCAST  chan- 
nels. 

segmentnum 

Arbitrary  integer.    Should  be  different  than  another 
user's  application. 

Only  first  call's  value  used. 

mname 

DIRECT    CONNECT    and    BROADCAST    {receiver 
only):  Name  of  machine  to  connect  to. 

BROADCAST  {broadcaster  only):  Required  but  ig- 
nored 

sendportnum 

DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  send  to  other  machine. 

BROADCAST  {broadcaster  only):  Number  (0-3076) 
of  port  to  be  used  for  broadcast. 

BROADCAST  {receiver  only):  Required  but  ignored 

receiveportnum 

DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  receive  from  other  machine. 

BROADCAST  {broadcaster  only):  Required  but  ig- 
nored 

BROADCAST  {receiver  only):  Number  (0-3076)  of 
port  to  be  used  for  broadcast. 

server 

"server":             Create  DIRECT  CONNECT  channel 
as  a  server. 

"client":              Create  DIRECT  CONNECT  channel 
as  a  client. 

"broadcast":       Create  BROADCAST  channel  as  a 
broadcaster. 

"receive":            Create  BROADCAST  channel  as  a 
receiver. 

instructure 

Address  of  Machine  structure  created  to  hold  channel 
information. 

freespace 

N/A 

Amount  of  space  to  be  used  for 
dynamic  memory  allocation. 

Only  first  call's  value  used. 
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VI.  performance 

A.    Introduction 

We  look  at  the  size  of  packets  from  our  protocols.  We  also  look  at  the  effect  of  real 
applications  on  the  network.  We  try  to  do  this  for  both  direct  connect  and  broadcast 
protocols.  However,  no  application  making  good  use  of  broadcast  protocols  exists. 
Hence,  we  used  a  direct  connect  test  application  and  replaced  the  channel  with  two 
broadcast  channels. 

B.      DATA  COLLECTION 

The  LANalyzer  EX  5500  network  analyzer  was  used  to  gather  Ethernet  statistics. 
Version  2.0  of  the  software  was  used.  The  LANalyzer  5500  is  a  COMPAQ  PORTABLE 

II  with  a  coprocessor  board  installed.  The  coprocessor  board  has  an  Intel  80286  CPU, 
an  Intel  82586  LAN  coprocessor,  and  two  MBytes  of  memory.  It  performs  packet 
collection,  packet  filtering,  and  network  statistics  calculation.  The  COMPAQ  PORTABLE 
n  processor  handles  user  software  control,  screen  updating  and  disk  I/O.  [Ref.  29] 

Samples  were  taken  while  direct  connect  applications  were  running  on   iris2  and 
iris3.   To  compare  direct  connect  protocol  with  the  broadcast  protocol,  test  programs 

were  used28.  Table  6.1  summarizes  the  information  collected.  These  programs  send  a 
character  string,  an  integer,  and  a  floating  point  number  in  a  rotating  sequence.  The 
messages  are  either  sent  to  the  machine  specified  on  the  command  line  or  are  broadcast 
to  all  machines  on  the  local  network  but  only  received  from  the  machine  specified. 


*  LANalyzer  is  a  registered  trademark  of  Excelan,  Inc. 

**  COMPAQ  PORTABLE  II  is  a  tradmark  of  the  COMPAQ  Computer  Corporation. 

28  See  programs  prog.c,  prog2.c,  gprog.c,  and  gprogl.c  in  Appendix  D. 
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Table  6.1     DIRECT  CONNECT  VERSUS  BROADCAST  STATISTICS 


Run 
Number 

Direct  Connect 

Number         Ave         Max 

of           Packet       Test 

„    .              Size         Load 
Packets         ,                 „ 
(bytes)           (%) 

Broadcast 
Number         Ave 
of            Packet 

Packets 

(bytes) 

Max 
Test 
Load 

(%) 

1 

1031 

91 

TO 

9498 

69 

1.0 

2 

1047 

111 

.05 

9860 

69 

1.0 

3 

465 

96 

<.05 

4000 

68 

1.0 

4 

698 

95 

.05 

2556 

68 

1.0 

5 

334 

103 

.10 

1262 

68 

1.0 

The  visual  simulation  application  measured  was  a  modified  version  of  the  driving 
simulator  [Ref.  7].  Table  6.2  summarizes  the  information  collected.  This  data  was 
taken  during  the  day29.  The  application's  communication  code  is  shown  in  Figure  5.7 
and  Figure  5.8.  One  trip  around  the  track  took  approximately  five  minutes.  Seven 
messages  are  sent  every  cycle  to  report  status.  Four  messages  are  sent  in  the  opposite 
direction,  as  required,  to  control  the  car.  One  circuit  was  driven,  on  autopilot,  for  each 
test  run.  There  were  about  500  cycles  per  test.  Approximately  3600  messages  were 
generated  per  test.  The  number  of  packets  sent  was  less  than  half  of  this.  The  apparent 
discrepancy  exists  for  two  reasons.  First,  each  packet  sent  also  generates  an 
Table  6.2     APPLICATION  NETWORK  USE  STATISTICS 


Run 

Number 

Number 
of 

Packets 

Average 

Packet 

Size 

(bytes) 

Peak 

Network 

Load 

(%) 

Peak 

Test 

Load 

(%) 

Average 

Network 

Load 

(%) 

1 

3747 

89 

13 

.10 

.5 

2 

3297 

89 

11 

.15 

1.0 

3 

4152 

89 

15 

<.05 

.5 

4 

2848 

89 

17 

.15 

.9 

5 

22830 

89 

17 

.10 

.3 

At  night,  with  less  competition  for  network  resources,  the  results  were  similar. 
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acknowledgement  packet  in  return.  By  acknowledging  each  packet,  the  stream  socket 
guarantee  of  delivery  and  proper  sequence  is  met.  Second,  after  the  first  packet 
(containing  the  first  message)  is  received,  the  remaining  three  or  six  messages  are 
immediately  sent.  The  receiving  process  has  often  not  yet  handled  the  first  one.  The 
remaining  messages  are  combined  into  one  and  all  are  read  as  one  block.  This  reduces 
the  interchange  to  a  typical  total  of  four  packets  per  cycle,  two  with  data  and  two  for 
acknowledgement.  Similarly,  four  packets  are  usually  generated  whenever  the  navigator 
process  issues  a  command  sequence  to  the  car. 

An  evaluation  of  a  five-workstation  application  [Ref.  11]  was  also  made.  This 
application  used  three  Symbolics  (syml,  sym3,  and  sym4),  expl,  and  iris2  to  perform  its 
tasks.  Statistics  were  similar  to  the  other  application,  but  the  Symbolics  irisflavor.lisp30 
exhibited  some  problem  behavior.  It  sent  three  packets  for  every  message.  The  first 
packet  contained  the  type  field  only.  The  second  packet  contained  both  the  type  field 
and  the  length  field.  The  third  contained  the  entire  message.  If  a  second  message 
immediately  followed  the  first,  three  more  packets  were  sent,  each  adding  one  field  to  the 
previous  packet.  Only  one  acknowledgement  was  received,  as  all  packets  in  a  group  had 
the  same  identification  number. 

C.     DISCUSSION 

Attempting  to  use  broadcast  protocol  with  the  simple  test  programs  failed.  One 
problem  encountered  was  overflow  of  the  sending  buffer  within  the  TCP/IP  layers.  The 
rapidity  of  attempted  transmission  was  the  cause.  Higher  network  loading  exacerbated 
the  problem.  When  the  test  application  was  slowed  down  with  printf  calls  (and  the 
output  redirected  into  a  file)  the  buffer  could  keep  up  with  sending  requests.    Using 


See  Appendix  C 
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broadcast  protocol  within  a  graphics  display  loop  should  pose  no  problems  unless 
numerous  data  elements  are  transmitted  at  one  time. 

Without  acknowledgement  packets,  broadcasting  put  fewer  packets  on  the  network 
than  did  the  direct  connect  protocol.  When  overall  load  was  haevy,  some  were  lost.  This 
poses  a  serious  problem  for  visual  simulation  applications.  Without  an  elaborate 
application-level  protocol,  the  receiving  process  will  never  know  what  was  intended  to 
be  sent.  Since  only  one  data  object  is  transmitted  at  a  time,  labeling  the  data  objects  is 
difficult.  All  that  is  available  is  to  alternately  send  different  types  and,  after  checking 
the  type  received,  make  a  determination  of  the  likely  intent  of  the  sending  process.  If  a 
block  of  data,  containing  different  types,  could  be  sent  as  a  single  message,  the  decoding 
problem  would  become  one  of  simply  sequence  checking.  Missing  status  packets  can  be 
safely  ignored  in  many  situations.  At  most,  a  simple  averaging  algorithm  can  smooth 
any  discontinuities  caused  by  a  missing  packet.  Timestamping,  with  a  virtual  timestamp, 
of  each  packet  would  eliminate  the  averaging  requirement. 

The  Symbolics  stream  version  is  much  less  efficient,  in  terms  of  network 
utilization,  than  is  the  Explorer's.  It  still  functions  correctly,  with  no  noticeable  delay. 
As  the  amount  of  data  to  transmit  increases,  the  Symbolics  flavor  will  eventually  have 
noticeable  performance  degradation. 

The  interconection  of  five  machines  loads  the  network  only  slightly  more  than  does 
that  of  two.  The  limitation  will  be  from  the  process  swap  overhead,  not  the  network. 

D.    Summary 

The  direct  connect  protocol  sends  fewer  packets  than  messages.  Half  of  the  packets 
sent  are  acknowledgements.  These  acknowledgements  provide  the  reliability  of  the 
direct  connect  protocol.  The  broadcast  protocol  sends  one  packet  for  each  message. 
These  packets  tend  to  be  smaller  than  those  for  the  direct  connect  protocol.    Until  a 
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mechanism  exists  to  bundle  several  messages  into  one  broadcast  packet,  the  broadcast 
protocol  is  of  small  value. 
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vn.  Conclusions  and  Recommendations 

A.      LIMITATIONS 

There  are  two  primary  limitations.  First,  the  Lisp  and  C  functions  differ  at  the  user 
level.  This  was  done  to  allow  each  to  be  used  readily  by  programmers  "thinking''  in  their 
respective  language.  We  have  found  this  to  be  confusing  to  students  who  are 
inexperienced  in  both  languages.  Second,  there  is  no  simple  means  to  transmit  a  block  of 
data  or  an  entire  file.  Each  data  element,  unless  it  is  part  of  an  array  of  characters,  must 
be  sent  separately.  This  was  done  to  "hit  a  middle  ground"  between  a  complex 
facility — printf  function— and  low-level  system  calls.  As  long  as  only  the  direct  connect 
protocol  existed,  this  was  only  an  annoyance.  As  discussed  in  Chapter  6,  this  is  a 
critically  limiting  factor  for  the  broadcast  protocol. 

The  port  to  BSD  UNIX  systems  without  shared  memory  and  semaphores  was  not 
completed.  The  socket  handling  aspects  are  portable,  but  the  shared  memory  aspects  are 
interwoven  throughout  the  system.  The  difficult  part  of  the  porting  will  be  designing  the 
message-passing  protocol  for  the  pipe  between  the  application  and  the  send  and  receive 
processes,  as  discussed  in  Chapter  4.  Other  specific  limitations  include: 

•  no  broadcast  capability  for  Lisp  machines 

•  no  server  capability  for  Lisp  machines 

•  limited  communication  error  handling — no  signals  are  sent  from  the  send  or  receive 
processes  to  the  application  process  if  they  encounter  problems 

•  limited  read/write  error  handling — a  read  or  write  of  the  wrong  type  will  be 
attempted  and  usually  produce  garbage 

•  no  out-of-band  capability 

•  Symbolics  iris-flavor.Iisp  creates  three  packets  per  message 
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B .  FUTURE  RESEARCH  AREAS 

Implementation  of  the  missing  structure  data  type  is  one  key  area  in  which  more 
work  could  be  done.  The  most  straight-forward  solution  to  this  would  be  to  add 
messages  to  the  send  section  of  the  shared  memory  array  without  signalling  the  send 
process  to  send  it  until  the  entire  block  was  ready.  Such  a  solution  eliminates  any  need  to 
change  the  receiving  functions  at  the  cost  of  either  an  additional  sending  function  or  an 
additional  parameter  to  the  existing  send  functions.  The  additional  send  function  would 
be  a  push  function  and  the  existing  send  functions  would  be  modified  to  never  signal  the 
send  process  to  send.  That  would  be  left  to  the  new  push  function.  Adding  a  parameter 
to  each  send  function  would  allow  any  send  function  to  push.  While  in  some  respects 
simpler,  changes  to  any  application  sending  a  block  of  data  would  have  to  carefully 
monitor  which  send  function  actually  is  pushing. 

Creation  of  a  Lisp  flavor  that  mimics  the  UNIX  functions  would  prove  useful  to  C 
programmers  who  find  a  need  for  Lisp  modules  in  their  visual  simulation.  Adding  server 
and  broadcast  capabilities  would  increase  the  applicability  of  the  protocols  to  future 
visual  simulation  projects.  Functions  to  break  complex  Lisp  objects  into  simple  ones  and 
then  combine  these  into  a  single  message  are  necessary  for  the  broadcast  protocol.  The 
Symbolics  version  should  be  corrected  to  send  a  packet  only  at  message  boundaries. 

C.  SUMMARY  AND  CONCLUSION 

The  routines  described  herein  have  already  proved  useful  to  researchers  at  the  Naval 
Postgraduate  School.  With  Ethernet  loading  never  exceeding  one  percent,  these  routines 
are  efficient  enough  to  use  without  concern.  With  the  additions  mentioned  above,  the 
goal  of  an  easy-to-use  yet  powerful  system  will  be  reached. 
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APPENDIX  A  -  IRIS  MODULE  DESCRIPTIONS 


1 .      io_singIe.c 

a.      Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application's  use  and 

functions  that  are  used  exclusively  by  them.   The  parameters  for  externally  accessible 

functions  are  described  below. 

i.       number  received 
number_rece ived(    instructure    ) 

Machine    *ins tructure ;       /*    includes 

char    *ins tructure . segment        a  pointer    to    the    shared   segment 
*/ 

ii.      read_character 

read_char ac  ter( instructure,charac  ter_ou t ) 

Machine    *ins t ructure ;      /*    includes 

char    *ins true ture . segment        a  pointer    to    the    shared   segment    */ 
char    *charac ter_out ;         /*   pointer    to   output    character    */ 

iii.    readjeharacters 

read_characters( ins t ructure, outarr ay, arr ay size) 

Machine    *  ins t rue ture ;      /*    includes 

char    *  ins t rue ture . segment        a  pointer    to    the    shared   segment    */ 
char   outarray[];         /*   output    character   buffer    */ 
int    arraysize;  /*    the   number   of   characters    to   be    returned   */ 

iv.     readjioat 

read_f loa t (instructure, float _out) 

Machine  * i ns t rue t ure ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 
float  *float_out;    /*  pointer  to  output  float  */ 

v.  readjnteger 

read_integer ( ins tructure, integer_out) 

Machine  *  ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 
int  * i n t ege r_ou t ;    /*  pointer  to  output  integer  */ 
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vi.  received Jype 

char  rece i ved_type (  instructure  ) 

Machine  *  ins t rue ture  ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
*/ 

vii.  write  joharacter 
wri  te_character( ins t rue ture, character_in) 

Machine  *ins t rue ture  ;   /*  includes 

char  * i ns t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem    the  semaphore  to  the  sender  */ 

char  *charac ter_in ;    /*  pointer  to  input  character  */ 

viii.  write  _characters 

wri  te_characters( instructure, inarray.arraysize) 

Machine  *  ins t rue ture ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t ructure . receivesem    the  semaphore  to  the  receiver 
char  *inarray;    /*  input  character  buffer  */ 
long  arraysize;      /*  the  number  of  characters  input  */ 

ix.  write  Jioat 

write_float (ins  true ture, float_in) 

Machine  *  ins t ructure ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins  true ture . sendsem    the  semaphore  to  the  sender  */ 
float  *float_in;    /*  pointer  to  input  float  */ 

x.  write  Jnteger 

write_integer( ins t ructure, integer_in) 

Machine  *  ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem    the  semaphore  to  the  sender  */ 
int  *integer_in;    /*  pointer  to  input  integer  */ 
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b.      Code  and  Description 


*  * 

*  TITLE     In t er -Compu t e r  Conmun ica t ion  Package 
i  o_s  i  ngle . c 
3.0 

15  December  1987 
Theodore  H.  Barrow 


*  MODULE 

*  VERSION 

* 

*  DATE 


* 
* 
* 
* 

* 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 

****************************************************** *******  ***************** 

* 

* 


*   HISTORY: 

* 


VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

27  May  1987 

Theodore  H.  Barrow 

Originally  part  of  support. c.   Contains  the  documented  read 
and  write  calls  for  use  by  the  application  prograrrmer. 

2.0 

21  October  1987 

Theodore  H.  Barrow 

Modified  read  routines  to  use  a  global  array  to  manage  the 
possibility  of  a  partial  message  receipt. 

3.0 

15  December  1987 

Theodore  H.  Barrow 


Modified  read  routines  to  use  part  of  a  buffer  set  instead  of  * 

the  global  array  to  manage  the  reception  of  a  partial  message.* 

****************************************************************************** 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

♦Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Vers* 
****************************************************************************** 

*  *         *  *  *  *     * 

*  *  *  *     * 
*****************************************************************************/ 


66 


io_single.c 


#include  "shared. h" 
#i  nc 1 ude  "gl  . h" 


/*  The  following  routine  copies  a  character  into  the  shared  segment. 

It  puts  the  type  CHARACTER_TYPE  in  the  first  byte  and  the 
length  0001  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 
*/ 

wri  te_character( ins  t  ructure ,character_in) 

Machine  *inst ructure;   /*  includes 

char  *instructure. segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem     the  semaphore  to  the  sender  */ 

char  *charac t er_i n ;    /*  pointer  to  input  character  */ 

f 

int  msgsize   =  5  +  CHARACTERS  I ZE;    /*  size  of  message  */ 

char  *senderstart  =  i ns t rue ture ->segment  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sent length  =  (long  * ) ins t rue ture->segmen t  +  WSENDEROFFSET ; 

/*  insert  the  type  code  */ 

*( senders  tart  +  4)  =  CHARACTER_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sprintf((senderstart  +  5),  "%04d" ,  CHARACTER_S I ZE ) ; 

/*  move  the  data  bytes  */ 

memepy ( da t as t ar t  ,  charac t er_in ,  CHARACrER_SIZE) ; 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
♦sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

•/ 

V(  inst  ructure ->s ends em) ; 

)    /*  wr i t e_char ac t er  */ 
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/*  The  following  routine  converts  an  integer  to  a  string  and  copies  it 

into  the  shared  se gme n t . 
It  puts  the  type  INTEGERJTTPE  in  the  first  byte  and  the  string  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

*/ 

wr  i  te_integer( ins  t  ructure , integer_in) 

Machine  *  ins t rue t ure ;   /*  includes 

char  *  ins t rue ture . segmen t    a  pointer  to  the  shared  segment 
int  i ns t rue ture . sendsem     the  semaphore  to  the  sender  */ 

int  *integer_in;    /*  pointer  to  input  integer  */ 

I 

char  in t ege r_s t r ing[20] ;   /*  string  for  integer  conversion  */ 

int  length;  /*  length  of  integer  string  */ 

intmsgsize;  /*  size  of  me  s  s  a  g  e  * / 

char  *senderstart  =  i ns t rue t ure ->segmen t  +  SEfOEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  *) ins t rue ture->segmen t  +  WSENDEROFFSET ; 

/*  convert  integer  to  string  */ 

sprintf(  in t eger_s t r ing , "%d  '  ,  *in t eger_in  ); 

/*  find  length  of  integer  string  and  thus  message  */ 
length  =  strlen(  in t eger_s t r ing  ); 
msgsize   =  5  +  length; 

/*  insert  the  type  code  */ 
♦(senderstart  +  4)  =  INTEGERJTYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr int f( ( senders  tar t  +  5),  "%04d" ,  length); 

/*  move  the  data  bytes  */ 

memepy ( da t as t ar t ,  in t eger_s t r ing ,  length); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 

indicating  that  he  can  reuse  the  shared  segment. 
*/ 
V(  instructure ->s ends  em)  ; 

)    /*  wr i t e_i n t ege r  */ 
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/*  The  following  routine  converts  a  float  to  a  string  and  copies  it 

into  the  shared  se  gme  n  t . 
It  puts  the  type  FLOAT_TYPE  in  the  first  byte  and  the  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

*/ 

wr  i  te_float ( ins  t  rue  ture , float_in) 

Machine  *  ins t rue t ure  ;   /*  includes 

char  *  ins t rue ture . segmen t    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem     the  semaphore  to  the  sender  */ 

float  *float_in;    /*  pointer  to  input  float  */ 

( 

char  f loa t_s t r ing [30] ;   /*  string  for  float  conversion  */ 

int  length;  /*  length  of  float  string  */ 

intmsgsize;  /*  size  of  message  */ 

char  *senderstart  =  ins t rue ture->segmen t  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  *) ins  true ture->segmen t  +  WSENDEROFFSET; 

/*  convert  float  to  string  */ 

sprintf(  float_string,  "%f "  ,  *float_in  ); 

/*  find  length  of  float  string  and  thus  message  */ 
length  =  s  t  r 1 e  n (  float_string  ); 
msgsize   =  5  +  length; 

/*  insert  the  type  code  */ 
♦(senderstart  +  4)  =  FLOATJTYPE; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr int f( ( sender s t ar t  +  5),  "%04d" ,  length); 

/*  move  the  data  bytes  */ 

memepy ( da t as t ar t ,  f 1 oa t_s t r ing ,  length); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 

indicating  that  he  can  reuse  the  shared  se  gme  n  t  . 
*/ 
V( instructure ->sendsem)  ; 

)    /*  wri te_f loat  */ 
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/*  This  routine  returns  the  type  of  data  received.  */ 

char  rece i ved_t ype (  instructure  ) 

Machine  *instructure;   /*  includes 

char  *  ins t rue t ure . segmen t    a  pointer  to  the  shared  segment 

*/ 

I 

return(  * ( i ns t rue ture ->segmen t  +  RECEIVEROFFSET  +  4)  ); 
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/*  This  routine  returns  the  number  of  data  items  received.  */ 
n  umb  er_received(  instructure  ) 
Machine  * i n s t rue t ur e ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 

( 

i  n  t  t  emp_  i  n  t ; 

char  *protocolho!d    =  ins t rue ture ->segmen t  +  PRCTTOCOLHOLDOFFSET ; 

long  *par t rece i ved    =  (long  * )pro t ocol ho  1 d ; 

long  *recei vedl eng t h  =  (long  *) ins t rue t ure->segmen t  +  'WRECEIVEROFFSET; 

char  *receiverstart   =  i ns t rue ture ->segmen t  +  RECEIVEROFFSET; 

/*  check  if  only  part  of  protocol  information  received  */ 

if(  *rece i vedleng th  <  5) 

{ 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  pro t ocolhold ,  recei ver s t ar t ,  *recei vedl eng th  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver( ins  t  rue  ture->se  gme  n  t ) ; 

V( instructure->rece  i vesem)  : 

wh  i  1  e (  rece i ver_i s_f ree ( i ns t rue t ure ->segmen t )  )  /*  wait  */  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 
memcpy(  (protocol  hold  +  *par t rece i ved  +  4),  ( receiver s t ar t  +  4), 
(5  -  *par t rece i ved)  ); 

1 
else 

I 

/*  copy  protocol  data  into  holding  area  */ 
memcpy(  pro t oco 1  hoi d ,  rece i ver s t ar t ,  9); 

/*  initialize  *par t recei ved  so  it  can  be  used  later  */ 
♦par t rece i ved  =  0; 

) 

/*  determine  the  length  of  the  received  integer  string  and  thus  message  */ 
sscanf(  prot ocolhold  +  5,  "%d" ,  &temp_int  ); 

switch(  *(pro t oco lhol d  +  4)  ) 

( 

case    CHARACTER_TYPE: 

re  t urn(    1    )  ; 

break ; 
case  INTEGER_TYPE : 

r  e  t  u  r  n  (  1  )  ; 

break ; 
case  FLOATTYPE: 

return(  1  )  ; 

break : 
case  CHARACrER_ARRAY_TYPE : 

return!  t emp_in t /CHARACTER. SIZE  ); 

break ; 
case  INTEGER_ARRAY_TYPE : 

return(  t  emp_i n t / INTEGER_SIZE  ); 

break ; 
case  FLOAT_ARRAY_TYPE : 

return!  t  emp_i n t /FLOAT_SIZE  ); 

) 
}   / *  n umb er_received  */ 
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/*  The  following  routine  returns  a  character  from  the  shared  segment. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*/ 

read_character(instructure,character_out) 
Machine  *instructure;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 
char  *charac t er_out ;    /*  pointer  to  output  character  */ 

{ 

/*  temporary  storage  for  move  of  received  data  or  for  protocol  information 

wh en  partial  receipt  * / 
char  temp[LARGESTREAD]  ; 

char  *protocolhold    =  ins t rue ture->segmen t  +  PROTOC0LH0LDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved    =  (long  * )prot ocolhold; 

int  msgsize  =  5  +  CHARACTER_SIZE;    /*  size  of  message  */ 

char  *recei vers t art   =  ins t rue ture ->segmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart       =  rece i ver s t ar t  +  9; 

long  *recei vedlength  =  (long  * ) ins t rue t ure->segmen t  +  WRECEIVEROFFSET; 

/*  check  if  first  part  of  protocol  information  is  missing  */ 
if(  *par t rece i ved  ==  0  ) 

( 

/*  check  if  only  part  of  protocol  information  received  */ 
if(  *receivedlength  <=  5) 

( 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  pro t ocolhol d,  rece i ver s t ar t ,  *rece i vedlength  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver( instruc  t ure->segmen t ) ; 

V(  instructure->rece  i vesem) ; 

while(  rece iver_i s_free ( ins t rue ture ->segment )  )  /*  wait  */  ; 


) 


I 


/*  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  */ 
msgsize    -=  *partreceived; 
datastart  -=  *par t rece i ved; 

/*  move  the  bytes  */ 

memcpy( charac t er_ou t ,  datastart,  CHARACTER_S I ZE ) ; 

/*  make  buffer  ready  for  next  read  */ 

r e se t_buf f e r (  receivedlength,  msgsize,  instructure,  datastart, 
CHARACTERSIZE,  par t received ,  rece i ve r s t ar t  ); 

(    /*  read_charac t er  */ 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  returned  integer. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*/ 

read_integer(instructure,integer_out) 

Machine  *  ins t rue t ure ;   / *  includes 

char  *instructure. segment    a  pointer  to  the  shared  segment  */ 

int  * i n t ege r_ou t ;     /*  pointer  to  output  integer  */ 

I 

char  in t ege r_s t r ing[LARGESTREAD] ;   /*  string  storage  for  received  data  */ 

char  *protocolhold    =  i ns t rue t ur e ->segmen t  +  PROTOCOLHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved    =  (long  *  )pro t ocolho Id; 

int  length;  /*  length  of  integer  string  read  */ 

long  s  e  gme  ntlength;  / *  length  of  data  of  partial  ma  s  s  a  g  e  * / 

int  msgsize;  /*  size  of  message  */ 

char  *rece i vers t art  =  ins t rue ture ->segmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  receiverstart  +  9; 

long  *recei vedlength  =  (long  * ) ins t rue t ure->segmen t  +  WUiCEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t _pro t oco 1 (  pro  toco  1  hoi d ,  pa r t r ece i ved ,  rece i ved 1 eng t h ,  receiverstart, 
instructure,  &length,  <Smsgsize,  &datastart  ); 

I*    check  if  only  part  of  data  has  been  received  */ 

if(  *receivedlength  <  msgsize  ) 

( 

get_data(  Asegmen t 1 engt h ,  receivedlength,  partreceived, 
in  t  ege  r_s  t  r  ing  ,  &datastart,  <&msgsize, 
receiverstart,  instructure,  Alength); 

/*  convert  to  string  */ 

i nteger_s t r ing [segment  1 ength  +  msgsize]  =  '\0*; 

I 
else 

( 

/*  move  the  integer  string  bytes  */ 
memepy ( i n t ege r_s t r ing ,  datastart,  length); 

/*  convert  to  string  */ 
i n t ege r_s t r i ng [ 1 eng t h ]  =  '\0'; 
) 

/*  convert  the  received  string  to  an  integer  */ 
sscanf(  in t eger_s t r ing ,  "%d" ,  integer_out  ); 

/*  make  buffer  ready  for  next  read  */ 

reset _buffer(  receivedlength,  msgsize,  instructure,  datastart,  length, 
partreceived,  receiverstart  ); 

)    /  *  read_in t  ege  r  */ 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  user  supplied  float. 

It  frees  the  receiver  side  of  the  shared  segment  if  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*/ 

read_ float ( instructure , float_out ) 

Machine  *  ins t rue t ure ;   /*  includes 

char  *  ins t rue t ure . segment    a  pointer  to  the  shared  segment  */ 

float  *float_out;    /*  pointer  to  output  float  */ 

( 

char  f loat_s t r ing [LARGESTREAD] ;   /*  string  storage  for  received  data  */ 

char  *protocolhold    =  ins t rue ture->segmen t  +  PROTOCOLHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved    =  (long  *  )pro t ocolhold; 

int  length;  /*  length  of  float  string  read  */ 

long  segmen t 1 eng th ;  /*  length  of  data  of  partial  massage  */ 

int  msgsize;  /*  size  of  message  */ 

char  *recei vers t art  =  ins t rue t ure->segmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  rece i vers t ar t  +  9; 

long  *recei vedlength  =  (long  * ) i ns t rue ture->segmen t  +  ^RECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t_prot ocol (  pro t ocolhol d,  par t rece i ved,  recei vedl eng t h ,  rece i vers t ar t  , 
instructure,  &length,  <&msgsize,  &datastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 
if(  * rece i vedl eng th  <  msgsize  ) 

I 

get_data(  Asegmen t 1 eng th ,  recei vedl eng th ,  par t rece i ved , 
f  loa  t_s  t  r  i  ng  ,  &datastart,  <&msgsize, 
rece i vers t ar t ,  instructure,  &length); 

/*  convert  to  string  */ 

f loa t_s t r ing [ segmen t 1 eng th  +  msgsize]  =  '\0'; 

) 
else 

I 

/*  move  the  float  string  bytes  */ 
memepy ( f 1 oa t_s t r ing ,  datastart,  length); 

/*  convert  to  string  */ 
f  loa t_s t r i ng [ leng t h]  =  '\0'; 
) 

/*  convert  the  received  string  to  an  float  */ 
sscanf(  f 1 oa t_s t r ing ,  "%{"  ,     float_out  ); 

/*  make  buffer  ready  for  next  read  */ 

reset _buffer(  receivedlength,  msgsize,  instructure,  datastart,  length, 
pa r t rece i ved ,  rece i ve r s t a r t  ); 

)   /*  read_float  */ 
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/*  The  following  routine  copies  characters  from  an  array 
into  the  shared  se  gme  n  t . 
It  puts  the  type  CHARACTER_ARRAY_TYPE  in  the  first  byte  and  the 

array  length  (in  bytes)  as  an  integer  into  the  next  four  bytes. 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

*/ 

wri  te_characters(instructure, inarray, arraysize) 

Machine  *  ins t rue t ure  ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . rece ivesem     the  semaphore  to  the  receiver. 

char  *inarray;    /*  input  character  buffer  */ 

long  arraysize;      /*  the  number  of  characters  input  */ 

I 

int  datasize  =  arraysize  *  CHARACTER_SIZE;  /*  size  of  data  field  */ 

int  ms  g  size   =5  +  datasize;  /*  size  of  me  s  s  a  g  e  * / 

char  *senderstart  =  ins t rue ture ->segment  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  *) ins t rue ture ->segmen t  +  WSENDEROFFSET; 

/*  insert  the  type  code  */ 

♦(senderstart  +  4)  =  CHARACTER_ARRAY_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr in t f( ( sender s t ar t  +  5),  "%04d" ,  ( in t )da t as i ze ) ; 

/*  move  the  data  bytes  */ 

memepy ( ( da t as t ar t ) ,  inarray,  datasize); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  5  +  datasize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 

indicating  that  he  can  reuse  the  shared  segment. 
•/ 
V( instructure ->s ends  em)  ; 

)    /*  wr  i t e_char ac t er s  */ 
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/*  The  following  routine  copies  bytes  from  the  shared  segment 
into  the  user  supplied  array. 
It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 
It  then  sends  a  wakeup  to  the  receiver  program. 
It  uses  an  input  structure  since  called  by  main  program. 

*/ 

read_characters(instructure,outarray,arraysize) 
Machine  *  ins t rue t ure ;   /*  includes 

char  *instructure. segment    a  pointer  to  the  shared  segment  */ 
char  outarrayf];     /*  output  character  buffer  */ 
int  arraysize;      /*  the  number  of  characters  to  be  returned  */ 

I 

char  *protocolhold    =  ins t rue ture ->segmen t  +  PR0TOCOLH0LDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved    =  (long  * )pro t ocolhold; 

int  length;  /*  length  of  character  string  read  */ 

long  segmen t I eng th ;  /*  length  of  data  of  partial  massage  */ 

int  datasize  =  arraysize  *  CHARA.CTER._S IZE ;  /*  size  of  requested  data  field  */ 

int  requestsize;  /*  size  of  message  */ 

int  msgsize   =  5  +  datasize;  /*  size  of  requested  message  */ 

char  *recei vers t art  =  ins t rue ture ->segment  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  rece i ver s t ar t  +  9; 

long  *rece i vedl eng t h  =  (long  *) ins t rue t ure->segmen t  +  A^RECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t_pro t ocol (  pro tocolhol d,  par t received ,  rece i vedl eng th ,  rece i vers t ar t  , 
instructure,  &length,  &nsgsize,  &datastart  ); 

/*  check  if  all  of  data  (or  more)  was  requested  */ 

if(  length  <=  arraysize  ) 

I 

/*  check  if  only  part  of  data  has  been  received  */ 

if(  *receivedlength  <  msgsize  ) 

( 

get_data(  &s  egmen t 1 eng t h ,  receivedlength,  partreceived, 
outarray,  &datastart,  &msgsize, 
receiverstart,  instructure,  &d  a  t  a  s  i  z  e  ) ; 

) 
else 

I 

/*  move  the  character  bytes  */ 
memc  py(outarray,  datastart,  length); 

) 

/*  make  buffer  ready  for  next  read  */ 

re se tbu f f e r (  receivedlength,  msgsize,  instructure,  datastart,  datasize, 
partreceived,  receiverstart  ); 
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else 

( 


/ *  move  the  by  t e  s  */ 
memcpy ( ou t ar r ay ,  datastart,  datasize); 

/*  make  buffer  ready  for  next  read  */ 

reset_buffer(  receivedlength,  msgsize,  instructure,  datastart,  datasize 
pa r t rece i ved  ,  rece i ve r s t ar t  ); 

/*  read_char ac t e r s  */ 
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/*  These  are  various  support  routines  used  by  several  of  the  preceding 
f unc  t  ions  . 

*/ 

re se t _buf f e r ( rece i ved 1 eng t h  ,  msgsize,  instructure,  datastart,  datasize, 
partreceived,  receiverstart) 

long  * rece i vedl eng th ;   /*  first  four  bytes  of  receive  part  of  shared  seg  */ 

int  msgsize;  /*  size  of  message  read  */ 

Machine  *  ins t rue t ure ;   /*  includes 

char  *  ins t rue t ure . segmen t    a  pointer  to  the  shared  segment 

int  ins t rue t ure . rece ivesem     the  semaphore  to  the  receiver.  */ 

char  *datastart;        /*  address  data  starts  in  receive  part  of  shared  seg  */ 

int  datasize;  /*  length  of  data  part  of  message  */ 

long  *par t rece i ved;     /*  length  of  message  received  in  previous  block  */ 

char  * r ece i ve r s t ar t ;    /*  address  receive  part  of  shared  seg  starts  */ 

I 

char  t emp[LARGESTREAD] ;   /*  temporary  storage  for  move  of  received  data  */ 

/*  free  the  receiver  segment  if  this  is  only  message  received  */ 
if(*receivedlength  ==  msgsize) 

I 

free_receiver( instruc  t ure->segmen t )  ; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 

indicating  that  he  can  reuse  the  shared  segment. 
*/ 
V( instructure->rece  ivesem)  ; 

) 

else     /*  shift  data  forward  in  shared  memory  segment  */ 

( 

*receivedlength  -=  msgsize; 

memcpy(temp,  (datastart  +  datasize),  (LARGESTREAD  -  msgsize)); 

memcpy(  ( rece ivers tar t  +  4),  temp,  (LARGESTREAD  -  msgsize)); 
) 

/*  reset  *par t rece i ved  for  next  read  */ 
*par t rece i ved  =  0; 

}    /*  reset_buffer  */ 
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ge t _pro t ocol (  p ro t oco 1  ho  1 d ,  par t rece i ved ,  rece i ved 1 eng t h  ,  receiverstart  , 
instructure,  length,  msgsize,  datastart  ) 

char  *protocolhold;     / *  protocol  holding  area  */ 

long  *partreceived;     /*  length  of  message  received  in  previous  block  */ 

long  *receivedlength;   / *  first  four  bytes  of  receive  part  of  shared  seg  *  / 

char  *rece i ve r s t ar t :    /*  address  receive  part  of  shared  seg  starts  */ 
Machine  *instructure;   /*  includes 

char  *  ins t rue t ur e . segmen t    a  pointer  to  the  shared  segment 

int  ins t rue ture . rece ivesem     the  semaphore  to  the  receiver.  */ 

int  *length;  /*  length  of  data  field  in  message  */ 

int  *msgsize;  /*  length  of  message  */ 

char  **datastart;       /*  address  data  starts  in  receive  part  of  shared  seg  */ 

I 

/*  check  if  first  part  of  protocol  information  is  missing  */ 
if(  *partreceived  ==  0  ) 

( 

/*  check  if  only  part  of  protocol  information  received  */ 
if(  *receivedlength  <=  5) 

( 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  pro tocolhold ,  receiverstart,  *rece i vedleng t h  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver(instruct  ure->segmen t ) ; 

V(  ins  t  rue tu re ->rece ivesem)  ; 

while(  rece iver_i s_free( ins t rue ture ->segmen t )  )  /*  wait  */  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 
memcpy(  (pro t ocol hoi d  +  *par t rece ived  +  4),  (receiverstart  +  4), 
(5  -  *par t rece i ved)  ); 

} 
else 

{ 

/*  copy  protocol  data  into  holding  area  */ 
memc py(  protocolhold,  receiverstart,  9); 

/*  initialize  *par t rece ived  so  it  can  be  used  later  */ 
*par t rece ived  =  0; 


/*  determine  the  length  of  the  received  data  string  and  thus  message  */ 
sscanf(  protocolhold  +  5,  "%d",  length  ); 
*msgsize   =  5  +  *length  -  *partreceived; 

/*  reset  datastart  to  c omp ensate  for  possible   partial  receipt  */ 
*datastart  -=  *par t rece ived ; 

I    /*  get_protocol  */ 
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get_data(  segmen t 1 eng t  li ,  receivedlength,  partreceived,  string_ array, 
datastart,  msgsize,  receiverstart,  instructure,  datasize  ) 

long  *  s  e  gme  ntlength;    / *  length  of  partial  data  * / 

long  ""rece i vedl eng t h ;   /*  first  four  bytes  of  receive  part  of  shared  seg  */ 

long  ""par  t  rece  i  ved  ;     /*  length  of  message  received  in  previous  block  */ 

char  s t r ing_array [ ] ;    /*  storage  for  incoming  characters  */ 

char  *""da  t  as  t  ar  t  ;       /*  address  data  starts  in  receive  part  of  shared  seg  */ 

int  ""msgsize;  /*  length  of  message  */ 

char  *rece i ver s t ar t ;    /*  address  receive  part  of  shared  seg  starts  */ 

Machine  *  in s t rue t ure  ;   /*  includes 

char  *ins t rue t ure , segmen t    a  pointer  to  the  shared  segment 

int  ins t rue t ure . rece ivesem     the  semaphore  to  the  receiver.  */ 

int  ""datasize;  /*  length  of  data  field  in  message  */ 

{ 

/*  determine  length  of  data  that  has  been  received  */ 
*segmen t I eng t h  =  * rece i ved 1 eng th  -  5  +  *pa r t rece i ved ; 

/*  copy  the  first  segment  of  data  to  holding  array  */ 
memcpy(  s  t  r  i  ng_a  r  ray  ,  *datastart,  ""segment  leng  t  h  ); 

/*  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  */ 
""msgsize    -=  * segmen t 1 eng t h  +  5  -  *par t rece i ved; 
♦datastart   =  receiverstart  +  4; 

/*  get  next  message(s)  */ 

free_receiver( instructure ->segmen t ) ; 

V( instructure->rece  ivesem)  ; 

whi 1 e (  rece iver_i s_free ( ins t rue t ure ->segmen t )  )  /*  wait  */  ; 

I*    cycle  through  as  many  messages  as  it  takes  */ 
wh  i  1  e (  *receivedlength  <  ""msgsize  ) 

{ 

/*  copy  the  next  segment  of  data  to  holding  array  */ 

memcpy(  &s  t  r  i  ng_ar  ray  [*  segmen  1 1  eng  t  h  ]  ,  ""datastart,  ""receivedlength  ); 

/*  reset  msgsize  and  segmen t 1 eng t h  to  correspond  to  partial  receipt  */ 
*msgsize        -=  ""receivedlength; 
*  segmen  1 1  eng  th  -=  ""receivedlength; 

/  *  get  next  message(s)  * / 

free_receiver(instructure ->segment ) ; 

V(  inst  ructure->receive  sem)  ; 

wh  i  1  e  (  rece  i  ve  r_i  s_free(  i  ns  t  rue  t  ure ->segmen  t  )  )  /""wait  */  ; 

I 

/*  copy  the  last  segment  of  data  to  holding  array  * / 

memcpy(  &s  t  r  i  ng_a  r  r  ay  [  *  segmen  t  1  eng  t  h  ]  ,  ""datastart,  ""msgsize  ); 

/*  reset  datasize  to  properly  reflect  last  segment  size  * / 
""datasize  =  ""msgsize; 

)    /""  get_data  *  / 
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a.      Calling  Protocols 

All  functions  in  this  module  are  meant  to  be  accessible  by  the  application. 
These  functions  set  up  and  tear  down  the  communications  path  between  two  machines, 
i.       deletemachinepath 

de 1 e  t  emachi  nepath(instructure) 

Machine  *  ins t rue ture ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *instructure.se  gme  nt  --  returned  ptr  to  the  shared  se  gme  n  t . 
int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number, 
int  ins t rue ture . rece ivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  port  number. 
*/ 

ii.      machinepath 

mach  i  nepa  t h( segmen  t  num,  mname  , sendpor  t num.  receivepor  t num.  server, instructure) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname  [ ] ;      /*  machinename  character  string  */ 

long  sendpor t num.  rece ivepor t num;    /*  send  and  receive  port  numbers  */ 
char  server [];     /*  this  character  string  is  either  "client"  or  "server". 
It  indicates  whether  the  sender/receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
mus  t  be  the  server  . 

*/ 
Machine  * i ns t rue ture ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segmen t  --  returned  ptr  to  the  shared  segment, 
int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number, 
int  ins t rue ture . rece i vesem  --  the  returned  receive  semaphore. 
*/ 

iii.    dynamicmachinepath 

dynami  cmach  i  nepa  t  h( segment  num,  mname  , sendpor  t num,  receiveport  num,  server  , 
in  structure, freespace) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

c  Ii  a  r  mn  ame  [  ]  ;      /  *  ma  c  h  i  n  e  n  ame  character  string  *  / 

long  sendpor t num,  rece i vepor t num;    /*  send  and  receive  port  numbers  */ 

char  server[];     /*  this  character  string  is  either  "client"  or  "server". 

It  indicates  wh ether  the  sender/receiver  should  open 

up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server. 

*/ 

Machine  * i ns t rue t u r e ;     /*  structure  to  hold  segment  and  semaphore  info: 

char  * i n s t rue t u re  .  segmen t  --  returned  ptr  to  the  shared  segment, 
int  ins t rue t ure . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue t ure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portn  unib  e  r  . 
int  i n s t rue t u re  .  rece i ve s  em  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portn  umb  e  r . 
*/ 
int  freespace;     /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 
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iv.     dynamicmachinepaths 


d  y  n  am  i  cma  chi  n  ep  a  t  h  s  (  n  urrma  chines  ,  s  e  gme  n  t  n  um ,  mn  ame  ,  sendpor  tn  um ,  receiveportn  um , 
server,  instructure, freespace) 


int  n  urrma  ch  i  ne  s  ;   /*  the  max 

long  segmentnum;   /*  the  key 

char  mn  ame  [ ] ;      / *  ma  chine 

long  sendpor 1 num,  rece i vepor t 

char  server[];     /  *  this  ch 

It  i  ndica  t 

up  as  ei  t h 

must  be  th 


Ma  chine 


*/ 
*inst  ructure; 


r 


char  *  ins  t  rue  t  ur e 
int  ins  t  rue  t ure  .  s 
int  ins  t  rue  t ure . s 

int  ins  t  rue  ture . r 


int  freespace;     /*  amount 
after  this  routine  h 

b.      Code  and  Description 


imum  number  of  other  machines  to  be  attached  */ 

to  use  for  the  created  shared  segment  */ 

n ame  character  string  * / 

num;    /*  send  and  receive  port  numbers  */ 

aracter  string  is  either  "client"  or  "server", 

es  whether  the  sender / rece iver  should  open 

er  a  client  or  server.  The  first  guy  open 
e  server. 

tructure  to  hold  segment  and  semaphore  info: 
.segment  --  returned  ptr  to  the  shared  segment, 
hmid  --  returned  system  generated  shared  mem  id 
endsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
eceivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 

of  freespace  desired  for  dynamic  memory  allocation 
as  been  called.  */ 


* 

* 

* 
* 

5.0  * 

* 


TITLE 

NCDULE 

VERSION 

DATE 

AUTHOR 


In t er -Compu t er  Communication  Package 
mp  a  t  h . c 


* 

* 

* 

* 

* 

* 

* 

* 

* 

*  * 

******************  ******  ***************************************.**  ************* 


31  May  1988 
Theodore  H.  Barrow 


HISTORY: 

VERSION:  1.0 

DATE    :  6  February  1987 

AUTHOR  :  Michael  J.  Zyda 

DESC.   :  Contains  routines  machinepath  and  de 1 e t emach i nepa t h  for 
link  creation/removal  at  a  high  level  of  abstraction. 

VERSION:  2.0 

DATE    :  27  May  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Converted  to  use  a  structure  for  ease  of  use. 

VERSION:  3.0 

DATE    :  21  October  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.  Added  function  dynami cmach i nepa t h  to  allow  dynamic  memory 
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VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


allocation  after  communications  link  established 

4.0 

15  December  1987 

Theodore  H.  Barrow 


* 

* 
* 

* 
* 
* 
* 
* 
* 

* 
* 
* 
* 

* 

*  * 

*  RECORD  OF  CHANGES  * 


Added  function  dynami  cmach i nepa t hs  to  allow  use  with  multiple  * 
links.  Modified  all  creation  routines  to  place  sequence  * 
numbers  at  end  of  command  line  for  send  and  receive  processes.* 


5.0 

31  May  1988 

Theodore  H.  Barrow 


Added  broadcast  and  receive  capability  -  one  process  spawned   * 


*  Vers  ion*   Date   *   Author 

Change  Description 


*  *   Affected    *Reqd* 

*    Modules    *Ve  r s * 

+  *  +  **  +  *******  +  ***  +  **  +  ****»+*  +  ****  +  **  +  ***  +  ****•***♦  +  **  +  **  +  *  +  *  +  *****  +  ***  +  ***+  +  *+<- 

*  *         *  *  *  *     * 

*  *  *  *     * 
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#include  "shared. h"    /*  my  special  defines  */ 
#i  nc 1 ude  <g 1  . h> 

deletemachinepath( instructure) 

Machine  * i n s t rue t ure  ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment. 

int  ins t rue t ure . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue t ur e . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number. 

int  instructure. receives  em  --  the  returned  receive  s  ema  p  h  o  r  e . 

We  base  it  on  the  receive  port  number 
*l 
I 

/*  kill  the  receiver  process...  */ 

ki 1 l_receiver( instructure ->segmen t , inst  rue  ture->rece  i vesem)  ; 

/*  kill  the  sender  process...  */ 

ki 1 l_sender( instruc  t ure->segmen  t  .instructure ->s ends em)  ; 

/*  detach  and  delete  the  shared  segment...  */ 

delete  sharedsegmen  t( ins tructure ->segmen  t , instructure ->shmi  d) ; 
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/* 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  macliinepa  t  h  routine  performs  the  following: 

(1)  creates  a  shared  se  gme  n  t  . 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
por  t  numbe  r  s . 

(3)  free_sender(se  gme  nt)  and/or  free_receiver(se  gme  n  t ) 

( 4 )  s  p  awn  s  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  server /c 1 i en t /broadcas t  0&"  ) : 
sy s t em( " rece i ve  sharedseg#  machinename  port#  server/client/receive  0&"  )  ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 

Machine  that  is  declared  in  the  calling  program. 

*/ 

mac hi  nepa  t h(  segmen  tnum.mname , sendpor  t num, receivepor  tnum, server , inst  ructure) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mname[];      /*  machinename  character  string  */ 

long  sendpor t num,  receivepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server[];      /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sende r / r ece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
mu st  be  the  server.   If  broadcast  wa nted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
*l 

Machine  *  ins t rue t ure ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segmen t  --  returned  ptr  to  the  shared  segment. 

int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number. 

int  ins t rue ture . rece ive sem  --  the  returned  receive  semaphore. 

*/ 

( 

char  *sharedsegmen t ( ) ;       /*  shared  segment  creation  function  */ 

int  semtran();  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];  /*  temp  character  arrays  */ 

/ *  create  the  shared  se  gme  n  t  *  / 

instructure ->segmen  t  =  shared segmen  t ( segmen  t  n um  .MAXSHAREDS I ZE , & i n s t  ructure ->shmi  d ) 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
i ns t rue t ure ->sendsem  =  semt ran( sendpor t num) ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
i n s t rue t u re ->rece i ve sem  =  semt r an ( rece i vepo r t num)  ; 

/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini  t_sha  red_bu  ffer( instructure ->segmen  t  )  ; 

/*  spawn  off  the  sender  process  */ 

iff  strcmp(  server,  "receive"  )  !=  0  ) 

( 
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/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
si  rcpy(  temp,SENDLOCATI0N)  ; 

s  t  r  c  a  t  (  t  emp  , "  "  )  ; 

/*  add  the  number  of  the  sha redsegmen t  in  text  */ 
spr  i  n  t  f ( t  emp2 , "%d" , instructure ->shmi  d  )  ; 
s  t  r  c  a  t ( t  emp , t  emp2 ) ; 
s  t  r  c  a  t ( t  emp  , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  (  t  emp.mname  )  ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  port  number  */ 

spr  in  t  f ( t  emp2 ,  "%d" , sendpor  tnum)  ; 

s  t  rca  t ( t  emp, t  emp2 ) ; 

s  t  r  c  a  t ( t  emp  , "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
strcat(t  emp , server) ; 
s  t  r  c  a  t ( t  emp , "  0 " ) ; 

/*  spawn  off  into  the  background  */ 
s  t  r  c  a  t ( t  emp , "&"  ) ; 

/ *  s p awn  off  the  sender  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  -  1  ) 

perror("SEND  system  call  failed"); 


/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
sende r_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  rece i ve r_has_da t a( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 

kill_sender(  ins t rue ture->segmen t ,  ins t rue t ure ->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 

if(  strcmp(  server,  "broadcast"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  rcpy(  temp.RECEIVELOCATION)  ; 
s  t  r  c  a  t ( t  emp , "  " )  ; 

/*  add  the  number  of  the  sharedsegmen t  in  text  */ 
spr  in t  f ( t  emp2 ,  "%d" , instructure ->shmid) ; 
s  t  rca  t ( t emp, t  emp2) ; 
s  t  r  c  a  t ( t  emp , "  "  )  ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t ( t  emp  mname ) ; 
s  t  rca  t ( temp  , "  " ) ; 

/*  add  the  port  n  umb  e  r  *  / 

sprint  f ( t  emp2 , "%d" , receiveport  num)  ; 

s  t  r  c  a  t  (  t  emp , t  emp2 ) ; 

s  t  r  c  a  t ( t  emp  , "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  r  c  a  t ( t  emp  .server); 
s  t  r  c  a  t ( t emp , "  0 " ) ; 

/*  spawn  off  into  the  background  */ 
s  t  re  a  t ( t  emp, "&" ) ; 
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/ *  s p awn  off  the  receiver  * / 
i  f (  s  y  s  t  em(  t  emp  )  ==  -  1  ) 

pe r ror ( "RECEIVE  system  call  failed") 


87 


mpath.c 

/* 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  dynami  cmach i nepa t h  routine  performs  the  following: 

(1)  creates  a  shared  se  gme  nt  and  attaches  it  to  the  ma  in  program  virtual 
space  after  an  allocation  of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
por  t  numbe r  s . 

(3)  f ree_sender ( segmen t )  and/or  f ree_rece i ve r ( segmen t ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  server/client/broadcast  0&" ) ; 
sy s t em(  " r ece i ve  sharedseg#  machinename  port#  server/client/receive  0&"  ) : 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  se  gme  nt  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

dynami  cmach i nepa  t h( segmen  tnum, mname  , sendpor  tnum,  rece  i vepor  tnum,  server , 
instructure, freespace) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  inn  ame [ ] ;      / *  ma  c  h  i  n  e  n  ame  character  string  *  / 

long  sendpor t num,  rece i vepor t num;    /*  send  and  receive  port  numbers  */ 

char  server[];     /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sende r / rece i ve r  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.   If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
*/ 

Machine  *  ins t rue t ure ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segmen t  --  returned  ptr  to  the  shared  segment. 

int  instructure  slim  id  --  returned  system  generated  shared  mem  id 

int  ins t rue t ure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  ins t rue t ure . rece ivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 
*/ 

int  freespace;     /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 

I 

char  *dynami  c sha redsegmen t ( ) ;    /*  shared  segment  creation  function  */ 

int  semtran();  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];      /*  temp  character  arrays  */ 

/*  create  the  shared  se  gme  nt  * / 

instructure ->segmen  t  =  dynamic  sha red segmen  t ( 1 , segmen  t n  um  .MAXSHAREDS I ZE . 

&instructure->s  hmi  d, freespace ) ; 

/*  create  the  send  s  ema  phore.  (unused  if  receiving  broadcast  me  ssages)  */ 
i ns t rue t u re ->sendsem  =  semt  ran( sendpor tnum)  ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
i ns t rue t ure ->rece i ve sem  =  semt  ran( rece i vepor t num)  ; 
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/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
i  ni  t_shared_buf  fer( instructure ->segmen  t ) ; 

/ *  s p awn  off  the  sender  process  *  / 

if(  strcmp(  server,  "receive"  )  !=  0  ) 

( 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st rcpy( temp.SENDLOCATION) ; 
s  t  r  c  a  t ( t  emp  , "  " ) ; 

/*  add  the  number  of  the  sha redsegmen t  in  text  */ 
s  p  r  i  n  t  f ( t  emp2 ,  "%d ",instructure->s  hmi  d ) ; 
s  t  re  a t ( t  emp , t  emp2) ; 
s  t  r  c  a  t ( t  emp ,  "  "  )  ; 

/*  add  on  the  machine  name  */ 
s  t  re  a  t  (  t  emp.mname)  ; 
s  t  re  a t ( t emp  , "  " ) ; 

/*  add  the  port  number  */ 

spr  in t  f ( t  emp2 , "%d" , sendpor  tnum)  ; 

strcat( t  emp , t  emp2 ) ; 

s  t  r  c  a  t ( t  emp  , "  "  )  ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  r  c  a  t ( t  emp  , server) ; 
s  t  r  c  a  t ( t  emp , "  0&"  ) ; 

/*  spawn  off  the  sender  into  the  background  */ 
i  f (  s  y  s  t  em( t  emp )  ==  -  1  ) 

perror("SEM)  system  call  failed"); 


else 


/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  rece i ve r_has_da t a( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 

kill_sender(  ins t rue t ure ->segmen t ,  ins t rue t ure ->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 

if(  strempt  server,  "broadcast"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  rcpy( temp.RECEIVELOCATION) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/ *  add  the  n  umb  er  of  the  sharedse  gme  n  t  in  text  * / 
spr  in  t  f ( t  emp2 , "%d" , instructure ->shmi  d) ; 
s  t  r  c  a  t ( t  emp ,  t  emp2 ) ; 
s  t  rca  t ( t  emp  , "  ") ; 

/*  add  on  the  machine  name  */ 
s  t  re  a  t  (  t  emp  ,mname  )  ; 
strcat(t  emp  , "  "  )  ; 

/*  add  the  port  number  */ 

spr  in  t  f ( t  emp 2 ,  "%d" , receivepor  tnum)  ; 

s  t  r  c  a  t ( t  emp  , t  emp2 ) ; 

s  t  r  c  a  t ( t  emp  , "  "  )  ; 

/ *  indicate  wh ether  a  server,  a  client,  or  a  broadcast  receiver  * / 
s  t  r  c  a  t  (  t  emp , server  )  ; 
s t  r  c  a  t (  t emp , "  0&"  ) ; 
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/*  spawn  off  the  receiver  into  the  background  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  -  1  ) 

perror( "RECEIVE  system  call  failed"); 
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/* 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  dynami  cmach inepa t hs  routine  performs  the  following: 

(1)  creates  a  shared  segment  large  enough  for  multiple  attachments 

and  attaches  it  to  the  main  program  virtual  space  after  an  allocation 
of  free  memo r y  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
por  t  number  s  . 

(3)  f ree_sender( segment )  and /or  f ree_rece ive r ( segment  ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  server/cl ient/broadcast  0&" )  ; 
sy s t em(  " rece i ve  sharedseg#  machinename  port#  server/client/receive  0&"  )  ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

•/ 

dynami  cmach  i  nepa  t  hs  (nurrmachi  ne  s  ,  segmen  t  num.mname  ,  sendpor  tnum,  receivepor  t  num, 

server , ins  t  rue  ture , freespace ) 

int  nurrmachines;   /*  the  maximum  number  of  other  machines  to  be  attached  */ 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mnamef];       /*  machinename  character  string  */ 

long  sendpor tnum,  rece i vepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server[];      /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sender/receiver  should  open 
up  as  either  a  client  or  server,  The  first  guy  open 
must  be  the  server.   If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
*/ 

Machine  * i n s t rue t u re ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *instructure.se  gme  nt  --  returned  ptr  to  the  shared  se  gme  n  t . 

int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  instructure. receives  em  --  the  returned  receive  s  ema  p  h  o  r  e . 

We  base  it  on  the  receive  portnumber, 
*/ 

int  freespace;      /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 

I 

char  *dynami  c sha redsegmen t (  ) ;      /*  shared  segment  creation  function  */ 

int  semtranl  );  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];  /*  temp  character  arrays  */ 

static  Boolean  firsttime  =  TRUE;  /*  flag  to  detect  multiple  requests  */ 

static  int  sequencenum    =  0;  /*  sequence  number  for  receive/send  */ 

static  int  totmachines;  /*  max  attachments  permitted  */ 

/*  check  for  first  time  called  and  establish  max  possible  attachments  */ 
i  f (  f  i  r s  t  t  ime  ) 
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totmachines    =    nuimiach  i  nes  ; 
f  i  rs  t  t  ime         =   FALSE; 

) 
else 

++sequencenum; 

I*    check  for  violation  of  maximum  attachments  */ 
if(  sequencenum  >=  totmachines  ) 

I 

per ror ( "mpa th :  Too  many  attachments  attempted"); 

exi  t (  -  1  )  ; 
) 

/*  create  the  shared  segment  */ 

ins  t  rue  t  ure ->segmen  t  =  dynamic  sharedsegmen  t  (  nurrmachines  ,  segment  num. 

MAXSHAREDSIZE, 
&instructure ->shmi  d.freespace) 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
ins t rue t ure->sendsem  =  semt  r an( sendpor t num)  ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
i ns t rue t ure->recei vesem  =  semt  ran( rece ivepor t num)  ; 

/  *  free  the  sender  and  receiver  parts  of  the  shared  se  gme  n  t  *  / 
ini  t_shared_buffer( ins  t  rue  ture ->segmen t ) ; 

/*  spawn  off  the  sender  process  */ 

if(  strcmp(  server,  "receive"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
strcpy(  temp.SENDLOCATION)  ; 
s  t  r  c  a  t ( t  emp , "  " )  ; 

/*  add  the  number  of  the  sharedsegmen t  in  text  */ 
spr  in  t  f ( t  emp2 , "%d" , ins  t  rue  ture->shmi  d) ; 
s  t  r  c  a  t  (  t  emp , t  emp2 ) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  r  c  a  t  (  t  emp  ,mname  )  ; 
s  t  r  c  a  t ( t  emp  , "  "  )  ; 

/*  add  the  port  number  */ 

spr  in  t  f ( t  emp2 ,  "%d" , sendpor  tnum) ; 

s  t  rca  t ( t  emp  , t  emp2) ; 

s  t  re  a  t ( t emp, "  " )  ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  r  c  a  t ( t  emp  , server) ; 
s  t  r  c  a  t ( t  emp  , "  " ) ; 

/*  add  the  machine  sequence  number  */ 
spr  i  n  t  f ( t  emp 2 ,  "%d" , sequencenum)  ; 
s  t  rca  t ( t  emp,  t  emp2  )  ; 

/*  spawn  off  into  the  background  */ 
s  t  rca  t ( t  emp, "&"  ) ; 

/ *  s p awn  off  the  sender  * / 
i  f (  s  y  s  t  em(  t  emp  )  ==  -  1  ) 

per ror ("SEND  system  call  failed"); 

) 
else 

( 

/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
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sender_is_free()  call  will  always  return  FALSE . 

A  similar  thing  does  not  have  to  be  done  for  r ece i ve r_ha s_da t a (  ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 
kill_sender(  i ns t rue t ur e ->segmen t  ,  i ns t rue t u re ->sends  em  ); 


/*  spawn  off  the  receiver  process  */ 

if(  strcmp(  server,  "broadcast"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
strcpy( temp.RECEIVELOCATION) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  number  of  the  sharedsegmen t  in  text  */ 
spr  in  t  f ( t  emp2 , "%d" , instructure ->shmid) ; 
s  t  r  c  a  t ( t  emp , t  emp2 ) ; 
strcat(t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  (  t  emp.mname  )  ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  port  number  */ 

spr  in  t  f ( t  emp  2 , "%d" .receiveport  num)  ; 

st  r  c  a  t ( t  emp  , t  emp2 ) ; 

s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  r  c  a  t ( t  emp , server) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  machine  sequence  number  */ 
spr  in  t  f ( t  emp2 , "%d" , sequence num)  ; 
s  t  r  c  a  t ( t  emp  , t  emp2 ) ; 

/*  spawn  off  into  the  background  */ 
s  t  rca t ( t  emp, "&"  ) ; 

/  *  s  p  awn  off  the  receiver  */ 
i  f (  s  y  s  t  em(  t  emp  )  ==  -  1  ) 

perror( "RECEIVE  system  call  failed"); 
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a.      Calling  Protocols 

This  module  contains  the  low-level  socket-managing  calls.    No  functions  in 
this  module  are  intended  for  application  programs.  This  module  is  only  linked  into  the 
send  and  receive  processes. 


b.      Code  and  Description 


/ 


************************  ******************** ********************************* 


*  TITLE 

* 

*  NODULE 

* 

*  VERSION 

* 

*  DATE 


In t er -Compu t e r  Conrnun ica t i on  Package 

ne  tV. c 

5.0 

31  May  1988 


*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 
****************************************************************************** 

*  * 


HISTORY: 
VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 


1.0 

19  November  1986 

Michael  J.  Zyda 

Contains  routines  connec t_se rver  and  connec t_c 1 i en t  to  allow 
two  machines  with  Unix  System  V  to  corrmunicate  via  sockets. 

2.0 

29  April  1987 

Mi  chae 1  J .  Zyda 

Converted  to  work  with  4 . 2BSD  sockets. 

3.0 

27  May  1987 

Theodore  H.  Barrow 


Eliminated  excess  variables,  some  unused  and  some  unnecessary.* 

4.0  * 

21  August  1987 

Theodore  H.  Barrow 

Improved  reliability  of  socket  connection  and  disconnection 

5.0 

31  May  1988 
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*  * 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 

*  DESC.   :  Added  s t ar t _broadcas t ( )  and  broadcas t _rece i ve ( )  to  provide 

*  datagram  sockets  for  broadcast  use.   These  sockets  use  the 

*  default  Internet  broadcast  addressing.  * 

****************************************************************************** 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

♦Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Vers* 

***********  +  ***  +  +  *********  +  *  ************************************************** 

*  4.1   *  4Jan88  *  T.  H.  Barrow        *  *  send.c       *4.0  * 

*  *    Changed  include  library  pathnames  for  IRIS  4D. *  receive. c    *4 . 0  * 

****************************************************************************** 

*  *         *  *  *  *     * 

*  *  *  *     * 
*****************************************************************************/ 
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/* 

Th  i  s  segmen  t  ,  when  1 i  nked  into  a  progr  am  on  a  compu  t  e  r  with  a  UNIX  4 . 2  BSD 

operating  system,  will  allow  the  program  to  corrmunicate  with  programs 

executing  on  other  computer  systems  over  an  Internet  network. 

*/ 

#define  TRUE  1 

/*  include  files  for  UNIX  4.2  BSD.   These  are  all  called  from  the  bsd 

subdirectory  in  /us r / inc 1 ude .   The  file  sys/types.h  also  exists  and  is 
included  when  bsd/ sy s / t ypes . h  is  used.   This  was  done  for  ease  of  change 
if  and  when  Silicon  Graphics  changes  the  include  library  structure.  */ 

#include  <sy s / types . h> 

#include  <sy s / socke t . h> 

#include  <bsd/ne t i ne t / in . h> 

#include  <bsd/ne t db . h> 


/ 


*********$***********************4^********%**************** 


The  connec t_se rve r ( remot e_c 1 i en t_name  ,  port_number)  function  performs 

the  actions  required  to  connect  a  server  system  to  a  remote  client  system 


*  4-  +  ******»•***'**+  +**+*******+**********+**********+*♦**+***** 


int  connec t_server ( remot e_c 1 i en t_name  ,  port_number) 

char  remo t e_c 1 i en t_name [ ] ;   /*  name  of  the  remote  client  system  */ 

int   port_number;  /*  port  number  to  the  remote  client  system  */ 

I 

char  *p t r_c I i en t_name  ;      /*  pointer  to  the  remote  client  system's  name  */ 

int  local_server_socket ;    /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

int  accept();  /*  function  that  accepts  a  connection  from 

a  remote  client  socket  */ 

int  remot e_c 1 ient_socke t  =  -1;   /*  socket  number  of  remote  client  system  */ 

/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address   =  (  AF_INET  }; 

long  remot e_c 1 i en t_addres s ;      /*  address  of  the  remote  client  system  */ 

short  remot e_c 1 i en t_por t ;        /*  port  number  of  the  remote  client  system  */ 

int  address_size;  /*  size  of  address  of  remote  client  system  */ 

/*  create  socket  structure  from  input  parameters  */ 

/*  get  a  pointer  to  the  remote  client  system's  name  */ 
p t r_c 1 i en t _name  =  r emo t e_c 1 i en t_name  ; 

/*  convert  the  remote  client  system  name  to  its  address. 

Note  that  ge t hos t byname  (  )  requires  a  pointer  to  a  pointer  *  / 
remot  e_c 1 i  en  t_addres  s  =  (long)gethost  byname  (&p  t  r_c 1 i  en  t _name  )  ; 

/*  set  the  remote  client  port  number  above  the  system  reserved  ports 

by  adding  the  remote  client  port  number  to  the  number  of  reserved  ports  */ 
remote_cl ient_por t  =  I PPORT_RESERVED  +  port_number; 

/*  remote  client  system  address  family  (Internet  in  this  case)  */ 
address. sin_family  =  AF_INET  ; 
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/*  place  the  remote  client  port  number  into  the  address  data  structure 

in  network  byte  order  */ 
addre s s . s i n_por t  =  h t ons ( remo  t e_c 1 i en t _por t ) ; 

/*  place  the  remote  client  system's  address  in  the  address  data  structure  */ 
address. si n_addr.s_addr  =  remo  t e_c 1 i en t _addr e s s ; 

/*  find  number  of  bytes  in  the  remote  client  address  */ 
address_size  =  s i zeof ( remo  t e_c 1 i en t _addr e s s ) ; 

/*  attempt  to  open  a  local  socket  */ 
Iocal_server_socket  =  socke t (AF_INET, SOCK_  STREAM, 0 ) ; 

i f ( local_serve r_socke t  <  0) 

per ror ( "Server  couldn't  open  a  local  socket:"); 
else 

( 

i f (bi nd( 1  oca l_server_socke t ,  (caddr_t  )&addres s ,  s i zeof ( addres s ) )  <  0) 
perror( "Server  couldn't  bind  address  to  local  socket:"); 

/*  set  the  maximum  number  of  remote  client  systems  to  be  connected  to  */ 
1 i  s  ten( local_server_socket ,  SCMAXCONN) ; 

printf ("Server  waiting  to  connect  to  %s  \n " , r emo  t e_c 1 i en t _name ) ; 

/*  attempt  to  accept  a  connection  */ 

r emo t e_c I i en t_socke t  =  accep t ( 1  oca l_se rve r_socke t ,  &address, 

&addres  s_s  i  ze ) ; 

i f ( remot e_c 1 i en t_socke t  <  0) 

( 

/*  an  error  occurred  in  the  server  attempting  to 

accept  a  connection  from  remote  client  system  */ 
per ror ( "Se rver  couldn't  accept  connection  from  remote  client  system:") 

shut  down( local_server_socket,  2); 
close( local_server_socket ) ; 

) 

/*  else  the  server  accepted  a  connection  from  the  remote  client  system  */ 


/*  return  the  socket  number  of  the  remote  client  system  */ 
re  t urn( remot  e_cl ient_socket ) ; 

J  /*  connec t_se rve r  */ 
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/*********************************************************** 

The  connec t _c 1 i en t ( remot e_se rve r_name  ,  port_number)  function  performs 
all  the  actions  required  to  connect  a  client  system  to  a  remote  server 
s  y  s  t  em 


*********************************************************** 


int  connec t_c 1 i en t ( remot e_server_name ,  port_number) 

char  remot e_serve r_name [] ;    /*  name  of  the  remote  server  system  */ 

int   port_number;  /*  port  number  to  the  remote  server  system  */ 

I 

int  local_c 1 i en t_socke t ;        /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

/*  function  that  connects  local  socket  to  remote  server  socket  */ 
i  n  t  connec  t  (  )  ; 

int  remot e_serve r_socke t ;       /*  socket  number  on  remote  server  system   */ 

/*  the  protocol  and  address  data  structure  specified  for  the  socket  */ 
static  struct  sockaddr_in  address  =  (  AF_INET  j; 

struct  hostent  *  r  emo  te_server_address;  / *  address  of  r  emo  te  server  syst  em  * / 

short  remot e_server_por t ;  /*  port  number  of  remote  system  */ 

/*  create  socket  structure  from  input  parameters  */ 

/*  convert  the  remote  server  system  name  to  its  address. 

Note  that  ge t ho s t byname  ( )  requires  a  pointer  only  in  this  case  */ 
remot e_se rve r_addres s  =  ge thos tbyname ( remot e_server_name ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeof ( addre s s  )  )  ; 

/*  copy  the  remote  server  address  structure  into  the  address  structure  */ 
bcopy ( remot  e_server_address->h_addr , 

(char  *  )&addre  s  s  .  s  in__addr  , 

remot  e_server_address->h_length) ; 

/*  set  remote  server  port  number  above  the  system  reserved  ports  by  adding 
the  user's  remote  server  port  number  to  the  number  of  reserved  ports  */ 
remote_server_por t  =  IPPORT_RESERVED  +  port_number; 

/ *   r  emo  te  server  syst  em  address  family(Internet  in  this  case)  *  / 
addre s s . s i n_f ami  1 y  =  AF_INET; 

/*  place  the  remote  server  port  number  into  the  address  structure 

in  network  byte  order  */ 
addre s s . s i n_por t  =  h t on s ( r emo t e_se r ve r_po r t ) ; 

/*  attempt  to  obtain  a  local  socket  */ 

local_cl ient_socket  =  socke t (AF_INET,  SOCK_STREAM,  0); 

i f ( 1  oca l_c 1 i en t_socke t  <  0) 

perror(" Client  couldn't  open  a  local  socket:"); 
else 

I 

/ *  place  Internet  address  f am ily  type  in  address  structure  */ 
addres s . s i n_f  ami  1 y  =  AF_1NET; 
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/*  attempt  to  connect  local  client  socket  to  remote  server  socket  */ 
remot e_serve r_socke t  =  connec t ( 1 oc a l_c 1 i en t _socke t ,  ( c addr_ t  )&add re s s  , 

s  i  zeof ( addres  s ) ) ; 

i f ( remot e_serve r_socke t  <  0) 

( 

/*  error  occurred  in  attempting  to  connect  to  remote  server  socket  */ 
perror(  "Client  couldn't  connect  to  the  remote  server  socket':"); 

shut  down( local_client_socket,  2); 
close(local_client_socket); 

/*  set  local_c 1 ien t_socke t  so  that  negative  value  is 

a  1 wa ys  returned  wh en  an  error  occurs 
*/ 
local_c 1 i en t_socke t  =  remot e_se rver_socke t ; 

) 

else 

/*  successfully  connected  to  the  remote  server  system  */ 

pr in t f( "Connec t ion  established  with  %s . \n" , remot e_serve r_name ) ; 


/*  return  the  socket  number  of  the  local  client  system  */ 
return( local _c 1 ient_socket ) ; 

)  /*  connec t_c 1 i en t  */ 
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Tlie  s  t  a  r  t_broadcas  t  (por  t_number  )  function  performs 

the  actions  required  to  initiate  a  datagram  broadcast  socket. 


************************************************************ 


i n t  s t ar t_broadca s t (por t_numbe r ) 

int   port_number;  /*  port  number  for  the  remote  receiver  system  */ 

I 

int  broadcas t_socke t ;    /*  local  socket  number  */ 

int  socket( ) ;  /*  function  that  opens  a  socket  */ 

int  se t sockop t ( ) ;        /*  function  that  sets  a  socket  to  allow  broadcast  */ 

int  on  =  TRUE;  /*  to  set  broadcast  toggle  on  for  socket  */ 

/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address   =  {  AF_INET  }; 

short  broadcas t_por t ;        /*  port  number  broadcast  heard  from  */ 

/*  create  local  socket  structure  from  input  parameters  */ 

/*  set  the  broadcast  port  number  above  the  system  reserved  ports 

by  adding  the  broadcast  port  number  to  the  number  of  reserved  ports  */ 
broadcas t_port  =  IPPORT_RESERVED  +  port_number; 

/*  system  address  family  (Internet  in  this  case)  */ 
address . s in_f ami  ly  =  AF_ INET  ; 

/*  place  the  port  number  into  the  address  data  structure 

in  network  byte  order  */ 
address . s in_por t  =  ht ons (broadcas t_por t ) ; 

/*  place  the  local  address  in  the  address  data  structure 

in  network  byte  order  */ 
address . sin_addr. s_addr  =  h t on  1 ( INADDR_ANY) ; 

/*  attempt  to  open  a  local  socket  */ 
broadcast_socket  =  socke t (AF_INET,SOCK_DGRAM,  0) ; 

i f( broadcas t_socke t  <  0) 

per ror ( "Broadcas t er  couldn't  open  a  local  socket:"); 
else 

( 

/*  set  the  broadcas t_socke t  for  broadcasting  */ 
if (set sockopt (  b roadcas t_socke t ,  SOL_SOCKET,  SO_BROADCAST , 
&on ,  sizeof(on)  )  <  0) 
pe r r or ( "Broadc a s t e r  couldn't  set  socket  to  broadcast:"); 

else  if(bind(  b roadc a s t _socke t ,  (struct  sockaddr  *)&address, 
s i zeof ( addre ss )  )  <  0) 
per ror ( "Broadcas t e r  couldn't  bind  to  local  socket:"); 
else 

( 

pr i n t f ( "Wa  i t i ng  to  broadc as t \n" ) ; 

I 
I 

/*  return  the  socket  number  */ 
return (broadcast_socket ) ; 

)  /*  s t a r t_broadca s t  */ 
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The  broadc as t_rece i ve( broadca s t e r_name  ,por t_number )  function  performs 
all  the  actions  required  to  set  up  a  broadcast  receiving  socket 


+  +  ******  +  ***  +  *  +  +  +  +  +  ***♦*********  +  ***  +  +  +  **  +  +  *+  +  *  +  *  +  +  +  +  +  +  +  <.*  + 


/ 


int  broadcast_receive(broadcaste  r_name  , por  t_n umber ) 

char  broadcas t er_name  [ ] ;    /*  name  of  the  broadcaster  system  */ 

int   port_number;  /*  port  number  for  the  broadcaster  */ 


( 


int  local_socke t ;        /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

int  broadcas t er_socke t ;  /*  socket  number  on  broadcaster  system   */ 

/*  the  protocol  and  address  data  structure  specified  for  the  socket  */ 
static  struct  sockaddr_in  address  =  {  AF_INET  }; 

struct  hostent  *b roadc a s t e r_addr e s s ;  /*  address  of  broadcaster  system  */ 

short  broadcas t e r_por t ;  /*  port  number  of  remote  system  */ 

/*  create  socket  structure  from  input  parameters  */ 

/*  convert  the  broadcaster  system  name  to  its  address. 

Note  that  ge thos t byname ( )  requires  a  pointer  only  in  this  case  */ 
broadcas te r_addres s  =  ge thos tbyname (broadcas ter_name ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s i zeof ( addres s  )  )  ; 

/*  copy  the  broadcaster  address  structure  into  the  address  structure  */ 
bcopy (broadc as  ter_address->h_addr , 

(char  *  )&addre s s . s i n_addr , 

broadcaster_address->h_length) ; 

/*  set  broadcaster  port  number  above  the  system  reserved  ports  by  adding 
the  user's  broadcaster  port  number  to  the  number  of  reserved  ports  */ 
broadcas ter_port  =  I PPORT_RESERVED  +  port_number; 

/*   broadcaster  system  address  f ami  1 y ( In t e rne t  in  this  case)  */ 
address . s i n_f  ami ly  =  AF_INET; 

/  *  place  the  broadcaster  port  n umb er  into  the  address  structure 

in  network  byte  order  */ 
address . s in_por t  =  h t ons ( broadcas t e r_por t  )  ; 

/*  attempt  to  obtain  a  local  socket  */ 
local_socket  =  socke  t  (AF_  INET,  SOCK_DGRAM,  0); 

i f ( 1 ocal_socke t  <  0) 

( 

pe r ror ( "Receiver  couldn't  open  a  local  socket:"); 

) 
else 

I 

/*  attempt  to  connect  local  socket  to  broadcaster  socket  */ 
broadc as t e r_socke t  =  connec t ( 1  oca l_socke t  ,  (struct  sockaddr  *)&address 

sizeof (address ) ) ; 
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i f (broadcas t er_socke t  <  0) 

( 

/*  error  occurred  in  attempting  to  insert  broadcaster  information  */ 
per ror ( "Rece i ve r  couldn't  find  broadcaster:"); 

shu t down( local_socke t ,  2); 
close( local_socket ) ; 

/ *  set  local_socket  so  that  negative  value  is 

always  returned  when  an  error  occurs 
*/ 
local_socket  =  broadcas te r_socke t ; 

) 

else 

/*  successfully  listening  to  the  broadcaster  system  */ 
pr i nt f( " ready  to  receive  from  %s  . \n" .broadcas t er_name ) ; 

) 

/*  return  the  socket  number  of  the  local  system  */ 
return( local_socket ) ; 

J  /*  broadcast_receive  */ 
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4.      receive.c 

a.  Calling  Protocols 

This  program  monitors  a  socket,  like  a  daemon.  It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line. 

b.  Code  and  Description 

;********************************************** ************************  +  *****.. 

*  * 

*  TITLE 


* 
* 

* 
* 
* 

* 
* 
*  * 

♦♦♦♦♦♦it********************************************************************** 


*  MODULE 

*  VERSION 


*  DATE 

* 

*  AUTHOR 


In t e r -Compu t er  Conmun ica t i on  Package 

receive.c 

3.0 

31  May  1988 

Theodore  H.  Barrow 


*   HISTORY: 

* 


VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

6  February  1987 

Mi  chae 1  J .  Zyda 

Background  process  to  receive  messages  over  link. 

2.0 

15  December  1987 

Theodore  H.  Barrow 

Added  capability  to  get  sequence  number  from  command  line 
and  use  it  to  get  offset  into  shared  memo  r  y  s  e  gme  n  t  . 

3.0 

31  May  1988 

Theodore  H.  Barrow 

Added  broadcast  receive  capability 


* 
* 
* 

* 

* 
* 
* 
* 
* 
* 
* 

* 
* 
* 
* 
* 
* 

* 

* 
*+******************************+**********++**+****************************** 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

♦Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Vers* 

*******************************************************+**+♦****+**+********** 

*  *         *  *  *  *     * 

*  *  *  *     * 

************************************ *+********+*++*+***********************+* 
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#include  "shared. h" 
#  i  n  c  1  u  d  e  "gl.h" 

ma  i  n ( a  rgc , argv  ) 

i n t  argc;    /*  argument  count  */ 

char  *argv[] ;    /*  pointers  to  the  passed  in  arguments  */ 

( 

/*  we  need  to  declare  character  variables  for  everything  passed  in  */ 

char  shmi ds t r [ 10] ;    /*  shared  segment  string  holding  the  integer  key*/ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  ^segment;         /*  character  pointer  to  the  shared  segment  */ 

int  receivesem;        /*  receive  semaphore  */ 

char  *sharedsegment( ); /*  create  shared  segment  function  */ 

char  mname[100];       /*  machine  name  */ 

char  por t s t r [ 10] ;      /*  port  number  string  */ 

long  portnum;  /*  port  number  pulled  from  the  string  */ 

char  server[10];       /*  server  string  */ 

char  seqnos t r [ 10] :     /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t_server ( ) ; 

int  connec t_c 1 i en t () ; 

int  broadcas t _rece i ve ( ) ; 

int  rece i ve r_i s_f ree( ) ; 

int  rece i ver_should_di e( ) ; 

int  semtran();        /*  semaphore  creation  routine.  * / 

/*  pull  out  the  strings  from  the  argument  list  */ 
i  f ( argc  <  5 ) 

I 

pr i n t f( "RECEIVE:  incorrect  argument  count !\n"); 
exi  t ( 1  )  ; 


/*  pull  out  the  shared  memory  string  */ 

strcpy(s  hmi  d  s  t  r,argv[l])  ; 

s  s  c  a  n  f  (  s  hmi  d  s  t  r , "%d " ,  &s  hmi  d ) ; 

/*  pull  out  the  machinename  string  */ 
s  t  r cpy  (mn  ame  , a  r gv  [2 ]  )  ; 

/*  pull  out  the  port  number  string  */ 
strcpy(portstr,argv[3]  ); 
sscanf(port  st  r ,  "%d" ,&por  t  num)  ; 
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*  create  the  receive  semaphore  */ 
eceivesem  =  semt ran(por t num)  ; 

*  pull  out  the  c 1 i en t / server  string  */ 
t  rcpy( server , argv[4] ) ; 

*  pull  out  the  sequence  number  string  */ 
f  (  argc  >  4  ) 

strcpy(seqnostr,argv[5]  )  ; 
sscanf(seqnostr, "%d" ,&sequencenum)  ; 

*  attach  to  the  shared  memory  segment  */ 

f (( int )(segment  =  (char  * ) shmat ( shmid ,  0,  0666))  <  0) 

pe rr or ( "RECEIVE: shmat"  )  ; 
exi t(0) ; 


*  create  the  shared  segment  address  to  use  */ 
egment  +=  sequencenum  *  MAXSHAREDS I ZE ; 

*  open  the  socket  connection  to  the  named  machine  */ 
f ( s  t  r cmp ( server , "server" )  ==  0 ) 

/*  we  should  open  as  the  server  */ 
socket  =  connec t_server  (mname ,por t num) ; 

Ise  i f( s t rcmp( server , "receive" )  ==  0) 

/*  we  should  open  as  the  broadcast  receiver*/ 
socket  =  broadcas t_rece i ve(mname  ,por t num)  ; 

lse 

/*  we  should  open  as  a  client  */ 
socket  =  connec t_c 1 ien t  (mname ,por t num) ; 


*  check  to  make  sure  socket  was  opened,  exit  if  not  */ 
f(socket  <  0) 

print f( "RECEIVE:  socket  connection  NOT  made!\n"); 
exi t(l) ; 


*  the  infinite  loop...  */ 

f ( s t rcmp( server ," receive" )  =  0) 
whi le(TRUE) 

/*  should  the  receiver  die???  */ 
if(receiver_should_die( segmen  t, receives em)) 

( 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 

detachsharedse  gme  n  t ( s  e  gme  n  t  )  ; 

shu t down( socke t ,  0); 

c lose( socke  t ) ; 

exi  t (0) ; 
) 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
i  f( receiver_i  s_free( segmen  t  )  ) 

( 

/*  check  socket  and  read  into  segment  if  proper  message  */ 
i f ( b roadcas t_i n t o_segmen t ( socke t  , segmen t  , mname , por t num)  >  0) 
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/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e 
the  data  has  been  read  out  */ 

P(  rece  i vesem)  ; 


)    /*  end  while  true  for  broadcasting*/ 
else 

while (TRUE) 

I 

/*  should  the  receiver  die???  */ 

if( receive r_should_die( segment , rece  i vesem) ) 

{ 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 

de  t  achsharedsegmen  t ( segment ) ; 

shu t down( socke t ,  0); 

c 1 ose( socke  t ) ; 

exi  t (0) ; 
) 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if( receive r_is_free( segment ) ) 

{ 

/*  read  socket  into  segment  */ 

read_ socke  t_in t o_segmen t ( socke  t , segment ) ; 
) 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e. 
the  data  has  been  read  out  */ 

P(  receive  sem)  ; 

}    /*  end  while  true  for  direct  connections*/ 
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5.      semaphore.c 

a.  Calling  Protocols 

This  module  repackages  the  low-level  semaphore  calls  into  a    P  and  a    V 
semaphore  operation.  No  functions  in  this  module  are  intended  for  application  programs. 

b.  Code  and  Description 


*   TITLE 


*  MODULE 

* 

*  VERSION 

*  DATE 


*   AUTHOR 


In t e r -Compu t er  Communica t i on  Package 


I*************************** ***+*******+***+*******************+******+**,.**** 

* 

* 

send . c  * 

1.0  * 


11  February  1987 
Mi  chae 1  J .  Zyda 


* 
* 

♦♦•♦♦♦♦♦it***********************************************************  ********* 

*  * 

*  HISTORY:  * 

* 

* 
* 
* 
* 
* 


1.0 

11  February  1987 

Mi  chae 1  J .  Zyda 

Implements  P  and  V  semaphore  operations  for  Unix  system  V. 
Based  on  an  example  from  Advanced  Unix  Progr  anrni  ng . 


*  VERSION 

* 

*  DATE 

*  AUTHOR 

*  DESC. 

* 

****************************************************************************** 

* 

*  RECORD  OF  CHANGES 


* Ve  r  s  i  on*   Da  t  e   *  Au  t  h  o  r 


*  *   Affected    *Reqd* 

*        *      Change  Description  *    Modules    *Vers* 

**********+*******I*************************+************+******************** 


***************************************************************************** 
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#include  <sy s / t ype s . h> 
#include  <sys/ipc.h> 
#include  <sys/sem.h> 

int  semtran(key)  / *  translate  s ema phore  key  to  ID   */ 
in  t  key ; 

( 

int  sid; 

if  ((sid  =  semget ((key_t )key, 1,06661  IPC_CREAT) )  ==  -  1 ) 

I 
per  ror ( " semge  t " ) ; 

} 
return(sid); 


static  void  semcal 1 ( s i d , op )  /*  call  semop   */ 
int  sid; 
int  op; 

( 

s  t  rue  t  sembuf  sb ; 

sb . sem_num  =  0; 
sb . sem_op  =  op ; 
s  b . s  em_  fig  =  0 ; 

i f ( semop ( s i d ,&sb , 1 )  ==  -1) 

( 

perror("s  emop " ) ; 


void  P(sid)   /*  acquire  semaphore   */ 
int  sid; 

{ 

s  emc  all(sid,  -1); 

} 


void  V(sid)   /*  release  semaphore  */ 
int  sid; 

{ 

s  emc  a  1  1  ( s  i  d  ,  1 )  ; 

) 
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6.      send.c 

a.  Calling  Protocols 

This  program  monitors  a  socket,  like  a  daemon.   It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line. 

b.  Code  and  Description 

/***************************************************************************** 

*  * 

*  TITLE     In t e r -Compu t er  Conmun ica t i on  Package  * 

*  * 

send . c  * 

* 

3.0  * 

31  May  1988  * 

Theodore  H.  Barrow  * 


*  MODULE 

*  VERSION 

*  DATE 

*  AUTHOR 

*  * 
***********  **************************************************  *<,***»*»»***, „,., 


* 
* 
* 
* 
* 
* 

* 
* 

* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 

****************************************************************************** 


* 

VERSION: 

* 

* 

DATE 

* 

* 

AUTHOR  : 

* 

* 

DESC. 

* 

* 

VERSION: 

* 

* 

DATE 

* 

* 

AUTHOR  : 

* 

* 

DESC. 

* 

* 

* 

VERSION: 

* 

* 

DATE    : 

* 

* 

AUTHOR  : 

* 

* 

DESC 

1  .0 

6  February  1987 

Mi  chae 1  J .  Zyda 

Background  process  to  send  messages  over  link. 

2.0 

15  December  1987 

Theodore  H.  Barrow 

Added  capability  to  get  sequence  number  from  corrmand  line 
and  use  it  to  get  offset  into  shared  memory  segment. 

3.0 

31  May  1988 

Th eodore  H.  Barr ow 

Added  broadcast  capability 


*  RECORD  OF  CHANGES 

* 

"Version*   Date   *   Author 

Ch  a  n  g  e  De  script  ion 


* 
* 

*  Affected    *Reqd* 

*  Modules    *Ve r s * 

****************************************************************************** 


***************************************************************************** 
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#include  "shared. h" 
#inc I ude  "gl . h" 


ma  i  n( argc  ,  ar gv  ) 

i  11 1  argc;     /*  argument  count  */ 
char  *argv[];     /*  pointers  to  the  passed  in  arguments  */ 

( 

/*  we  need  to  declare  character  variables  for  everything  passed  in  */ 

char  shmids t r [ 10] ;     /*  shared  segment  string  holding  the  integer  shmid  */ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  *segment;  /*  character  pointer  to  the  shared  segment  */ 

int  sendsem;  /*  send  semaphore  */ 

char  *sharedsegmen t ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];       /*  machine  name  */ 

char  portstr[10];      /*  port  number  string  */ 

long  portnum;  /*  port  number  pulled  from  the  string  */ 

char  server [10];       /*  server  string  */ 

char  seqnos t r [ 10] ;     /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

nt  socket;  /*  the  opened  socket  descriptor  */ 

nt  connec t_se rver ( ) ; 

nt  connec t_c 1 i en t () ; 

nt  s t a r t _broadcas t ( ) ; 

nt  sende r_has_da t a( ) ; 

nt  sender_should_di e( ) ; 

nt  semtran();        /*  semaphore  creation  routine.  */ 

/*  pull  out  the  strings  from  the  argument  list  */ 

i  f ( a  r  g  c  <  5) 

I 

pr in t f ( "SEND:  incorrect  argument  count!\n"); 

exi  t (  1  ) ; 

) 

/*  pull  out  the  shared  memo ry  string  * / 
s  t  rcpy ( shmi  dstr,argv[l]); 
sscanf(s hmi  d  s  t  r , "%d  " ,  &s  hmi  d ) ; 

/ *  pull  out  the  ma  c  h  i  n  e  n  ame  string  * / 
s  t  r  c  py  (mn  ame , a  r  g v [ 2 ] ) ; 

/*  pull  out  the  port  number  string  */ 
s t  rcpy ( po r  t  s t  r , a rgv [ 3 ] ) ; 
sscanf(portstr, "%d" ,&por  tnum)  ; 

/*  create  the  send  semaphore  */ 
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sendsem  =  semlran(portnnm)  ; 

/*  pull  out  the  client/server  string  */ 
st  rcpy( server, argv[4]  )  ; 

*  pull  out  the  sequence  number  string  */ 
f  (  a  r  g  c  >  4  ) 

strcpy( seqnostr,argv[5]  )  ; 
sscanf(seqnostr, "%d" ,&s  equencenum)  ; 

*  attach  to  the  shared  memo  r  y  s  e  gme  n  t  *  / 

f (( int )( segment  =  (char  *  )  shma  t ( shmi  d ,  0,  0666))  <  0) 

per  ror  (  "SEND:  shmat  "  )  ; 
exi t(0) : 


*  create  the  shared  segment  */ 
egment  +=  sequencenum  *  MAXSHAREDSIZE; 

*  open  the  socket  connection  to  the  named  machine  */ 
f ( s  t  r cmp ( server , "server" )  ==  0 ) 

/ *  we  should  open  as  the  server  * / 
socket  =  connec t_serve r (mname  ,  por t num)  ; 

lse  if(  strcmp(  server,  "broadcast"  )  ==  0  ) 

/*  we  should  open  as  a  broadcaster  */ 
socket  =  s t ar t_broadcas t (  portnum  ); 

lse 

/*  we  should  open  as  a  client  */ 
socket  =  connec t_c 1 i en t  (mname , por t num) ; 


*  check  to  make  sure  socket  was  opened,  exit  if  not  */ 
f(socket  <  0) 

pr in t f ( "SEND:  socket  connection  NOT  made!\n"); 
exi  t( 1) ; 


*  the  infinite  loop...  */ 

f(  strcmp(  server,  "broadcast"  )  ==  0  ) 
wh  i 1 e ( TRUE ) 

( 

/*  should  the  sender  die???  */ 

i  f( sender_shoul d_di  e ( segmen  t  , sendsem)  ) 

I 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 

de  t  ach shared segmen  t ( segmen  t  )  ; 

shu t down( socke t ,  1); 

c lose( socket  )  ; 

exi  t (0) ; 
) 

/*  if  there  is  data  in  the  shared  memo  r  y  s  e  gme  n  t  .  ...  * / 
i  f( sender_has_dat  a( segmen  t  )  ) 

I 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
s en d_ socke t_f  rom_  segmen  t ( socket .port  num,  segmen  t  )  ; 
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) 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P( sends  em)  ; 

)    /*  end  while  true  for  broadcasting*/ 
else 

wh  i 1 e ( TRUE ) 

( 

/*  should  the  sender  die???  */ 

if( sender_should_die( segment  , sends em) ) 

{ 

/*  exit  after  detaching  segment  and  cleaning  up  socket  * / 

de  t  achshar edsegmen  t ( segment ) ; 

shu t down  ( socke t  ,  1); 

c 1 ose( socke  t ) ; 

exi t(G) ; 
I 

/ *  if  there  is  data  in  the  shared  memo  r  y  s  e  gmen  t ,  ...  * / 
if( sende r_has_da  t  a( segmen t ) ) 

{ 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
wri  te_socke  t _f r om_  segmen t ( socke  t , segmen  t ) ; 

) 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

*/ 

P( sendsem)  ; 

J    /*  end  while  true  for  direct  connection*/ 
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7.      shared. h 

a.      Calling  Protocols 

This  module  has  all  the  predefined  constants  and  type  definitions.   It  must  be 
included  in  the  application. 
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b.      Code  and  Description 


* 


TITLE 

MODULE 

VERSION 

DATE 

AUTHOR 


In t e r -Compu t e r  Communication  Package 

shared.h 

4.0 

15  December  1987 

Theodore  H.  Barrow 


**  +  ******  +  *  +  *  +  +  +  +  ♦***  +  +  ,.****  +  +  »***  +  *  *  +  ***  +  +******  +  *****+*******  +  +  *******  +  **>♦.  +  * 

*  * 

*  HISTORY:  * 

*  * 

*  VERSION:  1.0  * 

* 

DATE    :  6  February  1987 

AUTHOR  :  Michael  J.  Zyda 

DESC.   :  Contains  all  defines  and  special  constants  for  shared 
memory  socket  system. 

VERSION:  2.0 

DATE    :  27  May  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Added  a  typedef  of  structure  for  use  by  various  routines. 
Added  message  types  for  high  level  read/write  protocol. 

VERSION:  3.0 

DATE    :  21  October  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Changed  dependencies  of  buffer  calculation  constants  so  that 
only  one  need  change.   Added  additional  message  types. 

VERSION:  4.0 

*  DATE    :  15  December  1987 

*  * 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 

*  DESC.   :  Added  field  to  buffer  set  so  that  each  link  would  have  its     * 

*  own  area  to  handle  partial  receipt  of  messages.  * 

+  *  +  +  **  +  +  ****  +  ***  +  *************  +  +  +.********<•*****  +  ***♦  +  *  +  *  +  +  *  +  ***  +  **  +  **  +  **  +  +  *  *  *  * 

*  * 

*  RECORD  OF  CHANGES  * 


>Ve 


r  s  i  on' 


Da  t 


Au  t  hor 


*  Affected 

*  Mo  d  u I e  s 


♦Reqd* 

*  *      Change  Description  *    Modules    *Ve r s * 

*  4.1   *  4Jan88  *  T.  H.  Barrow        *  *  *     * 

*  *    Changed  pathname  to  include  /usr  for  IRIS1     *  *     * 

*****************************  +  +  <,♦**.*  +  +  **  +  +  *  *  **********************  +  *  +  +  *****  +  */ 
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/* 

the  foil ow  ing  3  defines  are  the  changeable  par  ame  t  e  r  s 

LARGESTREAD  MJST  be  divisible  by  4 

*/ 

#define  SENDLOCATION  " /us r /work/ba r row/ share3 / send"  /*  the  name  of  the  program 

to  run  for  the  sender  */ 

#define  RECEIVELOCATION  "  /us r /work/bar  row/  share3/ rece i ve"  /*  the  name  of  program 

to  run  for  the  receiver  */ 

#define  LARGESTREAD  252       /*  the  largest  read  (i.e.  buffer  size)  */ 

/*  The  following  defines  are  constants  or  are  derived  from  LARGESTREAD  */ 

#define  SErOEROFFSET  (LARGESTREAD  +  4)    /*  the  sender  data  starts  here  */ 

#define  W5EIOEROFFSET  ( SEMDEROFFSET  /  4)  /*  long  word  offset  for  sender  data  */ 

#define  RECEIVEROFFSET  0      /*  the  receiver  data  starts  at  byte  0  */ 

#def ine  WRECEIVEROFFSET  0      /*  the  receiver  data  starts  at  long  word  0  */ 

#define  PROTOGOLHOLDOFFSET  ( SEM5EROFFSET  *  2)    /*  holding  area  starts  after 

sender  area  */ 
#define  MAXSHAREDS I ZE  (PROTOGOLHOLDOFFSET  +  12)  /*  the  number  of  bytes  in  the 

shared  se gme n  t  * / 

#define  CHARACTERJTYPE  'B*  /*  code  for  characters  */ 

#define  INTEGER_TYPE  'I'  /*  code  for  integers  */ 

#define  FLOAT_TYPE  "R'  /*  code  for  floats  */ 

#define  CHARACTER  ARRAY_TYPE  'C  /*  code  for  character  arrays  */ 

#define  INTEGER_ARRAY_TYPE  'J*  /*  code  for  integer  arrays  */ 

#define  FLOAT_ARRAY_TYPE  'S'  /*  code  for  float  arrays  */ 

#define  CHARACTER, SIZE   1  /*  character  size  in  bytes  */ 

#define  INTEGER_SIZE     sizeof(l)    /*  integer  size  in  bytes  */ 
#define  FLOAT_SIZE       sizeof(l.O)  /*  float  size  in  bytes  */ 

/*  the  following  is  the  structure  type  definition  needed  for  each  machine 

you  want  to  conmunicate  to... 
*/ 

t ypede f  s  t  rue  t  { 

char  *segment;    /*  ptr  to  shared  memory  segment  */ 

int  shmid;        /*  system  generated  shared  mem.  id  */ 

int  sendsem;      /*  semaphore  used  to  wakeup  the  sender 

process . 
•/ 

int  receives  em ;   / *  s ema  phore  used  to  wa  k  e  u  p  the 

receiver  process... 

*/ 

}  Ma  chine  ; 
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8.      shareseg.c 


Calling  Protocols 


This  module  contains  the  low-level  shared-memory  calls.  No  functions  in  this 
module  are  intended  for  application  programs. 

b.      Code  and  Description 

*+**************+***************+******+***************+**************+++++** 


/ 

*  * 

*  TITLE     In t er -Compu t er  Conmun ica t i on  Package  * 

*  * 

*  MODULE    rshareseg.c  * 

*  * 

*  VERSION:    3.1  * 

*  * 

*  DATE    :  24  February  1988  * 

*  * 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 
****************************************************************************** 

* 
* 
+ 
* 
* 

* 

* 

* 
+ 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


HISTORY: 
VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

6  February  1987 

Mi  chae 1  J .  Zyda 

Contains  routines  to  manage  shared  memory  segment.   Creation 
attachment,  detachment  and  deletion  are  all  covered. 

2.0 

21  Oc  tober  1987 

Theodore  H.  Barrow 

Added  function  dynami  csharedsegmen t  to  allow  dynamic  memory 
allocation  after  cormiuni cat  ions  link  established. 

3.0 

15  December  1987 

Theodore  H.  Barrow 


Modified  function  dynami  c sha redsegmen t  for  use  with  multiple 
links.   First  call  does  shared  segment  creation.   Subsequent   * 

calls  return  address  for  the  next  buffer  set.  * 

****************************************************************************** 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

♦Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Ve  r  s  * 

********************************  *******  *************************************** 

*  3.1   *  24Feb88*  T.  H.  Barrow        *  *   none        *     * 

*  *   Added  compatibility  for  IRIS  4D.  *  *     * 

*****************************************************************************/ 
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^include  <sy s / sy smac ros . h> 
# include  <stdio.h> 
#include  <sy s / t ypes . h> 
#include  <sys/ipc.h> 
#include  <sys/shm.h> 
#i  nc 1 ude  <gl  . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE   IRIS4D 

#else 

#define  MACHINE   IRIS3000 

#endi  f 

char  *sharedsegmen t (key.nbytes, shmid) 
long  key;      /*  the  key  to  use  for  the  segment  */ 
long  nbytes;  /*  the  number  of  bytes  in  the  segment  */ 
int  *shmid;   /*  returned  shared  memory  id  name  */ 

I 

char  *buf;  /*  temp  char  pointer  */ 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

/*  allocate  a  shared  memo  r  y  s  e  gme  n  t  * / 

if(  (*shmid  =  shmget(  key,  nbytes,  0666  I  IPC_CREAT  ))  <  0  ) 

( 

perror("s  hmg  e  t " ) ; 
exi  t(0) ; 

) 

/*  attach  to  the  shared  memo  r  y  s  e  gme  n  t  * / 
if((int)(buf  =  (char  * ) shmat ( * shmi  d ,  0,  0666))  <  0) 

{ 

perror( "s  hma  t " ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RMID,  Ajunkbuf  )  ==  -  1  ) 

perror(  "s  hmc  t 1 "  ) ; 
exi  t(0) ; 

) 

/*  return  the  pointer  to  the  shared  segment  */ 
return(buf) ; 
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char  *at  t  ach_wi  t  hin_da  t  asegmen  t  (.  key,  size,  shmid,  freespace  ) 

long  key;  /  *  the  key  to  use  for  the  se  gme  n  t  *  / 

long  size;         /*  the  number  of  bytes  in  the  segment  */ 

int  * shmid;       /*  returned  shared  memory  id  name  */ 

int  freespace;    /*  amount  freespace  desired  for  dynamic  allocation  */ 

{ 

char  *enddata,  *buf;         /*  temporary  address  pointers  */ 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

char  *  s  b  r  k  (  )  ,  *ma  1 1 o c ( ) ; 

/*  allocate  a  shared  memory  segment  */ 

if(  (*shmid  =  shmget(key,  size,  0666  I  IPC_CREAT)  )  <  0  ) 

I 

per ror ( " shmge  t " ) ; 
exi  t(0) ; 

) 

/*  Ensure  at  least  as  much  unallocated  space  as  freespace  indicates. 
Normally  the  top  of  the  data  region  is  incremented  more  than  the 
minimum  required  to  meet  the  malloc()  request.   Using  malloc() 
and  free()  ensures  that  this  mechanism  is  available  for  subsequent 
dynamic  memory  allocations.   Direct  use  of  sbrk( )  system  call 
causes  the  malloc()  mechanism  to  fail  on  subsequent  allocation 
requests.   freespace  is  cast  to  unsigned  to  meet  malloc()  spec.  */ 

free(  malloc(  ( un s i gned) f ree space  )); 

/*  find  the  top  of  data  region  */ 
endda  ta  =  sbrk(0); 

/*  round  up  to  the  next  page  boundary  for  attachment  of  shared 

memory  segment  */ 
buf  =  (char  * ) ( ( in t ) endda t a  -  ( ( in t )endda t a  %  SHVLBA)  +  S1MLBA)  ; 

/*  reset  top  of  data  region  to  be  above  shared  segment  */ 
if(  brk(  buf  +  size  )  <  0  ) 

{ 

pe  r ror ( "brk" ) ; 

/*  Since  there  was  an  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RMID,  Ajunkbuf  )  ==  - 1  ) 

perror(  "s  hmc  t 1 "  ) ; 
exit(-l); 

) 

/*  attach  to  the  shared  memo  r  y  s  e  gme  nt  at  the  calculated  address  * / 

if(  ( int ) shmat ( * shmid,  buf,  0666)  <  0  ) 

I 

perror( "s  hma  t " ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RMID,  &junkbuf  )  ==  -  1  ) 

perror(  "s  hmc  t  1  "  ) ; 
exi  t (0) ; 

I 

re  t  urn(  buf  ) ; 
)   / *  a  t  t  ach_wi  t  h  i  n_da  t  asegmen  t  (  )  */ 
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char  *dynami c shar edsegmen t ( nunmachi ne s ,  key,  nbytes,  shmid,  freespace) 

i  n  t  nunmach i ne s ;  /*  maximum  number  of  machines  to  be  initiated  */ 

long  key;         /*  the  key  to  use  for  the  segment  */ 

long  nbytes:      /*  the  number  of  bytes  in  the  segment  */ 

int  * shmid;       /*  returned  shared  memory  id  name  */ 

int  freespace;    /*  amount  freespace  desired  for  dynamic  allocation  */ 

( 

static  Boolean  first  time  =  TRUE;  /*  allows  for  multiple  calls  */ 

static  char  *startshared;  /*  start  of  shared  memo ry  space  * / 

static  int  *holdshmid;     /*  holds  shmid  for  subsequent  calls  */ 

i  f (  f  i  r  s t  t ime  ) 

( 

switch(  MACHINE  ) 

( 

case  IRIS4D: 

startshared  =  sharedsegmen  t  (  key,  nurrmachi  nes  *nby  t  e  s  ,  shmid  ); 

break ; 
case  IRIS3000: 

startshared  =  (char  * ) a t t ach_wi t h in_da t a segmen t (  key, 

nurrmach  ine  s  *nby  t  es  ,  shmid,  freespace  ) 

break ; 
d  e  f  a  u  1  t  : 

perror(  "shareseg:  Unknown  machine"  ); 

J   /*  switch(  MACHINE  )  */ 

holdshmid  =  shmid; 
f irst  t ime  =  FALSE; 

) 
else 

( 

/*  start  next  buffer  immediately  above  last.   Return  the  same  shmid 

for  all  buffers.   Assumes  all  buffers  are  same  size  (true  if  all 

from  same  shared. h  definition.  */ 
startshared  +=  nbytes; 

* shmid  =  *holdshmid; 

) 

/*  return  pointer  to  the  proper  buffer  in  the  shared  segment  */ 

return(  startshared  ); 
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detachsharedse  gme  nt(se  gme  n  t ) 

char  ^segment;    /*  segment  to  detach  from  */ 

( 

int  returnvalue; 

i  f  (  (  i  n  t  )  s  e gmen  t  %  SfM_BA  !  =  0  ) 

re  t urn(  1  ) ; 
else 

( 

if(  returnvalue  =  s  hmd  t ( s  e  gme  n  t )  <  0  ) 

perror("s  hmd  t " ) ; 
return(  returnvalue  ); 


de  1  e  t  e  sharedsegmen  t ( segment  , shmid) 

char  *  segment;    /*  character  pointer  to  the  shared  segment  */ 

int  shmid;        /*  shared  memory  id.  .  .  */ 

( 

int  re  t urnva I ue ; 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

/ *  detach  fr om  the  shared  se gme nt  and  set  returnvalue  * / 
if(  returnvalue  =  de t achsharedsegmen t ( segment )  ==  0  ) 

/*  remove  the  shared  segment  from  the  system  and  reset  returnvalue  */ 
if(  returnvalue  =  shmc  t 1 ( shmi  d ,  IPC_RMID,  &junkbuf)  <  0  ) 
per ror ( " shmc t 1 " )  ; 

return(returnvalue) ; 
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9.      support.c 

a.      Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application's  use  and 

functions  that  are  used  exclusively  by  other  routines.    The  parameters  for  externally 

accessible  functions  are  described  below. 

i.       receiver _has_data 
int    receiver_has_data( instructure) 

Machine    *  ins t rue ture ;      /*    includes 

char    *  ins t rue ture . segment         a   pointer    to    the    shared    segment    */ 

ii.      sender js-free 

int    sender_i s_free( ins  true ture ) 

Machine    *  ins t rue ture ;       /*    includes 

char    *  ins t rue ture . segment        a   pointer    to    the    shared    segment    */ 
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b.      Code  and  Description 


***************************************************************************** 


*  TITLE 

*  MDDULE 

* 

*  VERSION 

* 

*  DATE 


In t e r -Compu t er  Conmun ica t i on  Package 

suppo  r  t . c 

4.0 

31  May  1988 

Theodore  H.  Barrow 


*  AUTHOR 

* 

***************  *******  ******  *******************************  ******************* 
* 

*  HISTORY: 

* 

*  VERSION:  1.0 

* 

*  DATE    :  6  February  1987 

* 

*  AUTHOR  :  Michael  J.  Zyda 

*  DESC.   :  Contains  support  routines  for  shared  memory  conmun i ca t i on s 

*  system. 

* 

*  VERSION:  2.0 

DATE    :  27  May  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Converted  functions  called  by  the  application  program  to  use 
a  structure  for  ease  of  use. 

VERSION:  3.0 

DATE    :  21  October  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Removed  functions  for  reading  from  and  writing  to  the  shared 
memory  segment  by  the  application  program. 

VERSION:  4  0 

*  DATE    :  31  May  1988 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  + 

*  DESC.   :  Added  functions  bi oadcas t_ in t o_segmen t  and  * 

*  send_socke t _f rom_segmen t  for  broadcasting  over  datagram  socket* 

****************************************************************************** 


RECORD  OF  CHANGES 


♦Version*   Date   *   Author 

Change  Description 


*  *   Affected    *Reqd* 

*    Modules    *Vers* 

****************************************************************************** 

*  *         *  *  *  *     * 

*  *  *  *     * 
*****************************************************************************/ 
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#include  "shared. h" 

#i  nc  I  ude  <gl  .  h> 

#include  <bsd/ sy s / t ype s . h> 

#include  <sy s / socke t . h> 

#include  <bsd/ne t i ne t / i n . h> 

# include  <bsd/netdb.h> 

/*  the  following  routine  sets  up  buffer  area  */ 

ini  t_shared_buffer( segmen  t ) 

char  *segment;     /*  pointer  to  the  shared  segment  */ 


free_sender(  segment  ); 

free_receiver(  se  gme  n  t  ) ; 

•(segment  +  PR0TOCOLH0LDOFFSET  +  9)  =  *\0'; 


/*  the  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
valid. 

*/ 

free_sender( segment ) 

char  *  s  e  gme  nt;    / *  pointer  to  the  shared  se  gme  n  t  * / 

I 

/*  the  following  line  zeroes  the  first  four  bytes  of  the  sender  part 

of  the  shared  memory  segment,  'segment'  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 
*/ 
♦((long  *)segment  +  WSErOEROFFSET)  =  0; 


/*  this  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
val id. 

*/ 

free_receiver( segmen  t ) 

char  *  segment;    /*  pointer  to  the  shared  segment  */ 

( 

/*  the  following  line  zeroes  the  first  four  bytes  of  the  receiver  part 

of  the  shared  memory  segment,  'segment'  is  a  character  pointer. 

I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 
*/ 
♦((long  *)segment  +  WRECEIVEROFFSET)  =  0; 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 
*/ 

int  receiver _h as _data( instructure ) 

Machine  *in structure;   /*  includes 

char  *  ins t rue t ure . segmen t    a  pointer  to  the  shared  segment  */ 


f(*((long  *)  inst rue ture->segmen t  +  WRECEIVEROFFSET)  >  0) 
return(TRUE) ; 
else 

return(FALSE) ; 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  non-zero. 
•/ 

int  sende r_has_da t a( segmen t ) 

char  *segment;    /*  pointer  to  the  shared  segment  */ 

I 

f(*((long    *)  segment    +  WSEfOEROFFSET)    >    0) 
return(TRUE) ; 
else 

return(FALSE)  ; 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  less  than  zero. 
*/ 

int  receiver_should_die(se  gme  n  t  ) 

char  *segment:    /*  pointer  to  the  shared  segment  */ 

I 

if(*((long    *)  segment    +  \M*ECE  IVEROFFSET )    <   0) 

( 

return(TRUE) ; 

) 
else 

( 

re turn( FALSE) ; 

) 

) 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  less  than  zero. 
*/ 

int  sende r_shou 1 d_d i e ( segmen t ) 

char  *segment;    / *  pointer  to  the  shared  segment  */ 

I 

if(*((long    *)  segment    +  W5EIOEROFFSET)    <   0) 

I 

return(TRUE) ; 

} 
else 

( 

return(FALSE) ; 

) 
) 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  non-zero. 
*/ 

i  ii  t  rece  i  ve  r_i  s_f  ree(  segmen  t  ) 

char  *  s  e  gme  nt:    / *  pointer  to  the  shared  se  gme  n  t  * / 

[ 

if(*((long  *)  segment  +  V.RECEIVEROFFSET)  ==  0) 

( 

return(TRUE) ; 

) 
else 

( 

re turn( FALSE) ; 

) 

) 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 
*/ 

int  sende r_i s_f ree ( i ns t rue t ure  ) 

Machine  * i ns t rue t ur e  ;   /*  includes 

char  * i ns t rue ture . segmen t    a  pointer  to  the  shared  segment  */ 


( 


if(*((long    *)instructure->segment    +  WSEM>EROFFSET)    ==   0) 

( 

return(TRUE) ; 

) 
else 

( 

return(FALSE)  ; 
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/*  the  following  routine  reads  on  the  input  socket  into  the  receiver  segment.*/ 

read_socket_int  o_segmen  t ( socke  t , segment ) 

int  socket;    /*  a  socket  descriptor  */ 

char  *  s  e  gme  nt;  /*  a  ptr  to  the  shared  se  gme  n  t  * / 

( 

long  nbytes;    /*  the  number  of  bytes  read  in  */ 
char  templLARGESTREAD] ; 

/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
s  e  gme  n  t  . 

*/ 

nbytes  =  r e ad ( socke t , t emp , LARGESTREAD) ; 

if(nbytes  <=  0) 

I 

/*  the  following  routine  calls  are  commented  out  for  the  following 
reason : 

nbytes  <=  0  means  that  the  socket  has  been  broken. 

This  routine  is  called  by  the  receiver  process  so  the  only 
intelligent  thing  to  do  is  to  terminate  the  receiver  process, 
i.e.  call  exi  t .  .  . 

perror ( " read" ) ; 

printf  ("READ_SOCKET_INTO_SEGMEOT:  number  of  bytes  read  =  %d\n" , nby t es ) 
*/ 

shutdown(  socket,  2  ); 
c  lose(  socke  t  ) ; 
e  x  i  t  (  1 )  ; 
) 

/*  copy  the  data  into  the  shared  segment  */ 
memcpy( ( segment  +  RECEIVEROFFSET  +  4 ) , t emp  ,nby t es ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 
*((long  *)  segment  +  WRECEIVEROFFSET)  =  nbytes; 
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/*  the  following  routine  writes  the  data  from  the  sender  side 
of  the  shared  se  gme  nt  to  the  socket  */ 

write_soeket_f  rom_segmen ((socket ,s egmen  t ) 

i n t  socket;    /*  socket  descriptor  */ 

char  *segment;    /*  pointer  to  the  shared  segment  */ 

( 

long  nbytes;    /*  the  number  of  bytes  to  write  */ 
char  temp[LARGESTREAD] ; 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
s egmen  t . 

V 

memcpy( temp, ((char  *)segment  +  SENDEROFFSET  +  4), 

*((long  *)segment  +  WSENDEROFFSET) )  ; 

/*  write  the  data  to  the  socket  */ 

nbytes  =  wr i t e ( socke t , t  emp,  *((long  *) segment  +  \*5ENDEROFFSET) )  ; 

if (nbytes  <=  0  I  I  nbytes  !=  *((long  * ) segment  +  W5ETOEROFFSET) ) 
( 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 

sende  r  process. 

pe  r  ror ( "wr  i  t  e"  )  ; 

print  f(  "\MUTE_SOCKET_FROvl_SECMENT:    number    of    bytes  written   =  %d\n" , nby t es ) ; 

pr in t f( "Number    of    bytes    in    shared    segment    =  %d\n" , *( ( long    *)segment    +  WSErOEROFFS 

*/ 

s hut  down  (  socket,  2  )  : 

c  lose(  socke  t  ) ; 

exi  t ( 1) ; 

I 

/*  free  the  sender  se  gme  n  t  * / 
free_sender( s egmen  t ) ; 
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/*  The  following  routine  receives  on  the  input  datagram  socket. 

If  the  message  matches  the  mname  and  portnum  it  is  copied  into  the 
receiver  area  of  the  shared  memo  r  y  s  e  gme  n  t  . 

0  is  returned  if  the  message  does  not  match  mname  and  portnum, 
the  number  of  bytes  read  is  returned  if  it  does  match.  */ 

int  broadcast_int  o_segmen  t ( socke  t , segmen  t  .mname , por  t  num) 

int  socket;    /*  a  socket  descriptor  */ 

char  *  s  e  gme  nt ;  / *  a  ptr  to  the  shared  se  gme  n  t  * / 

char  mname  [] ;   /*  machine  name  of  broadcaster  */ 

long  portnum;   /*  port  number  of  broadcaster  */ 


long  nbytes;  /*  the  number  of  bytes  read  in  */ 

char  temp[LARGESTREAD] ; 

int  flags  =  0;  /*  flags  =  0  indicates  none  set  */ 

struct  sockaddr_in  who;  /*  Internet  structure  for  message  sender  address  */ 

int  who  1  en;  /*  length  of  received  address  struct  who  */ 

struct  hostent  *b roadcas t er ;    /*  pointer  to  structure  with  info  on 

broadc aster  * / 

static  long  broadcas t_address ;  /*  address  of  broadcaster  */ 

static  short  broadcas t_por t ;    /*  port  of  broadcaster  */ 

static  Boolean  first  time  =  TRUE; 

/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment.  This  also  allows  checking  for  match  with  desired  broadcaster. 

*/ 

nbytes  =  recvfrom(  socket,  temp,  LARGESTREAD,  flags, 

(struct  sockaddr  *)&who,  Awholen  ); 

if(nbytes  <=  0) 

( 

perror( " recvfrom:  " ) ; 

} 
else 

I 

i  f (  f  i  r  s  t  t  ime  ) 

I 

/*  determine  desired  broadcaster  address  and  port  */ 

broadcas t_po r t  =  h t ons ( ( shor t  )  por t num)  ; 

broadcaster     =  (struct  hostent  *)  ge t ho s t byname  (  mname  ); 


I 


bcopy(  broadca s t er ->h_addr ,  (char  *  )&broadcas t_addre s s 
broadc a s t e r ->h_l eng t h  ); 


if(  ( broadcas t_addre s s  ==  who . s i n_addr . s_add r )  && 
( broadcas t_por t     ==  who . s in_por t )  ) 
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/*  copy  the  data  into  the  shared  segment  */ 
memcpy( ( segment  +  RECEIVEROFFSET  +  4) , t emp  ,nby tes ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 
*((long  *)  segment  +  WRECEIVEROFFSET)  =  nbytes; 


else 


nby  tes  =  0; 

/*  Set  nbytes  to  0  so  return  of  function  indicates  no  match  */ 


re  t  urn(  nby t  es  )  ; 
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/*  the  following  routine  sends  the  data  from  the  sender  side 
of  the  shared  se gme nt  to  the  socket  for  broadcast  *  / 

send_socke  t _f  rom_segmen  t ( socket  .port  num,  s  egmen  t ) 
int  socket;  /*  socket  descriptor  */ 

long  portnum;     /*  port  number  of  broadcaster  */ 
char  *  segment;    /*  pointer  to  the  shared  segment  */ 

( 

long  nbytes;    /*  the  number  of  bytes  to  write  */ 

char  temp[LARGESTREAD] ; 

short  broadcas t er_por t ; 

static  Boolean  first  time  =  TRUE; 

static  struct  sockaddr_in  net  wo  r  k  =  {  AF_ INET  );  / *  structure  for  broadcast 

addr e  s  s  * / 

i  f (  f  i  r s  t  t  ime  ) 

( 

broadcas ter_port  =  I PPORT_RESERVED  +  portnum; 

/*  Set  up  broadcasting  address  structure  */ 

ne twork . s i n_f  ami  1 y       =  AF_INET; 

network. si n_addr . s_addr  =  h t onl ( INAEDR_BROADCAST) ; 

ne twork . s i n_por t         =  h tons (broadcas t er_por t ) ; 

f irst t ime  =  FALSE; 

) 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segmen  t  . 

*/ 

memcpy( temp, ((char  *) segment  +  SEM)EROFFSET  +4), 

♦((long  *)  segment  +  WSEtOEROFFSET ) ) ; 

/*  broadcast  the  data  through  the  socket  */ 

nbytes  =  sendto(  socket,  temp,  *((long  *)  segment  +  WSEtOEROFFSET) ,  0, 

(struct  sockaddr  *)&network,  s izeof (ne twork)  ); 

if (nbytes  <=  0  I  I  nbytes  !=  *((long  *) segment  +  WSEN)EROFFSET) ) 
( 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 

sender  proce  s  s . 

*/ 

pe  r ror ( "wr  i  t  e" ) ; 

pr  int  f  (  ,r\MlITE_SOCKET_FRCM_SEavlENr:  number  of  bytes  written  =  %d\n  "  ,  nby  t  e  s  )  : 
pr in t f ( "Numbe r  of  bytes  in  shared  segment  =  %d\n" , * ( ( 1 ong  *) segment  +  WSENDEROFFSET 
shut  down  (  socket,  2  ); 
c  lose (  socke  t  ) ; 
exi  t ( 1 ) : 
I 

/  *  free  the  sender  se  gme  n  t  * / 
free_sender( se  gme  n  t ) ; 
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/*  the  following  routine  deletes  the  sender  by  writing 
a  negative  byte  count  into  the  shared  segment 
and  then  waking  up  the  sender. 

*/ 

ki 1 l_sender( segmen  t , sends em) 

char  *  s  e  gme  nt;     /  *  p  t  r  to  these gme  n  t  * / 

int  sendsem;  /*  semaphore  to  the  sender  */ 

I 

/*  write  a  negative  number  into  the  byte  count  field.  */ 
*((long  *)  segment  +  "WSETOEROFFSET)  =  -1; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  sender  program. 

the  sender  will  read  the  bad  byte  count  and  exit. 
*/ 
V(  sendsem)  ; 


/*  the  following  routine  deletes  the  receiver  by  writing 

a  negative  byte  count  into  the  shared  se  gme  n  t 

and  then  waking  up  the  receiver. 
•/ 

kill_receiver( segmen  t , receives  em) 

char  *segment;    /*  ptr  to  the  segment  */ 

int  receivesem;  /*  semaphore  to  the  receiver  */ 

( 

/*  we  do  not  wait  until  the  receiver  segment  is  free  here 
as  the  process  that  calls  this  routine  should  already 
have  read  the  last  piece  of  data. 

*/ 

/*  write  a  negative  number  into  the  byte  count  field.  */ 
*((long  *) segment  +  WRECE1VEROFFSET)  =  -1; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
the  receiver  will  read  the  bad  byte  count  and  exit. 

*/ 

V(  r ece  i  ve  sem)  : 
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APPENDIX  B  -  TI  EXPLORER  MODULE  DESCRIPTIONS 

All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 

1 .      Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application's  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  iris 

(defun  iris  (x)      ;where  x  is  number  of  iris  machine  desired 

b.  start-iris 

(defmethod    (conver sat i on-wi th- i r i s    :start-iris) 
() 

c.  set- iris 

(defmethod  ( conversat ion-wi th- i ri s  :get-iris) 
() 

d.  put-iris 

(defmethod    ( conve r s a t ion-wi  t h- i r i s    :put-iris) 
( obj  ec  t  ) 
(let*    ((buffer    (cond 

((equal    (type-of    object)     'bignum)     (convert-number-to-string    object)) 

((equal     (type-of    object)     'fixnum)     (convert-number- to-string    object)) 
((equal    (type-of    object)     "float)    (convert -number- to-string    object)) 
((equal     (type-of    object)     'string)    object) 
(t    "error")     )) 

e.  stop-iris 

(defmethod    (conversat ion-wi th- i r is    :stop-iris) 

() 

f.  reuse-iris 

(defmethod  ( conversat i on-wi th- i r i s  :reuse-iris) 
() 
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2.      Code  and  Description 


(defmacro  loopfor  (var  init  test  expl  &optional  exp2  exp3  exp4  exp5) 
' ( prog  ( ) 

(setq  ,var  ,init) 

tag 

,  expl 

,  exp2 

,  exp3 

,  exp4 

,  exp5 

(setq  ,var  (1+  ,var)) 

(if  (=  ,var  .test)  (return  t)  (go  tag))  )  ) 

(defun  conve r t -numbe r- t o- s t r ing  (n) 
(pr inc -  to- s t r ing  n)  ) 

(defun  conve r t - s t r ing- t o- in t ege r  (str  &optional  (radix  10)) 
(do  ((j  0  (+  j  1)) 

(n  0  (+  (*  n  radix)  ( di gi t -char -p  (char  str  j)  radix)))  ) 
((=  j  (length  str))  n)  )  ) 

(defun  f ind-pe r iod- index  (str) 
(catch  "exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  "."  0)) 
(throw  'exit  x)  )  )  )  ) 

(defun  ge t - 1 e f t s i de -of  -  real  (str  &optional  (radix  10)) 
(do   ((j  0  (1+  j)) 

(n  0  (+  (*  n  radix)  (di gi t -char -p  (char  str  j)  radix)))  ) 

((or  (null  (digit-char-p  (char  str  j)  radix))  (=  j  (length  str)))   n)  )  ) 

(defun  ge t - r i gh t s i de -of  -  real  (str  &optional  (radix  10)) 
(do  ((index  (1+  ( f ind-pe r iod- index  str))  (1+  index)) 
(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  (digit-char-p  (char  str  index)  radix))))  ) 
((=  index  (length  str))  n)  )  ) 

(defun  conver t - s t r ing- t o- real  (str  &optional  (radix  10)) 

(+  (float  ( ge t -  1 e f t s i de -of  -  real  str  radix))  ( ge t - r igh t s ide-of -  real  str  radix))  ) 

(defvar  * t cp- hand  1 e r  1  *  (send  i p :  :  * t cp- hand  1 e r*  :get-port)) 
(defvar  * t cp- handl e r2*  (send  ip : : * t cp-handl er*  :get-port)) 


(defvar  * i r i s 1 -por t 1*  1027) 

(defvar  * i r i s 1 -por t 2*  1026) 

(defvar  * i r i s 1  - addres s*  3221866502) 

(defvar  * i r i s2- addres s*  3221866504) 

(defvar  * i r i s3 - addres s*  3221866505) 

(defvar  *dest -address*   nil) 


;  this  is  the  send  port 

;  this  is  the  receive  port 


;  the  tcp-ip  or  internet  address 
;  look  in  network  configuration 


(defun  iris  ( x ) 

(cond  ((equal  x  1)  (setq  *dest -address*  *irisl-ad dress*)) 

((equal  x  3)  (setq  *dest -address*  *iris3-ad dress*)) 
(t  (setq  *des t - addres s*  * i r i s2- addre s s* ) )  )  ) 

(defflavor  conve r sa t ion-wi t h- i r i s  ( ( t a  I k i ng-por t - numbe r     * i r i s  1 -po r t  1  *  ) 

(listening-port- numbe  r   *irisl-port2*) 
(talking-port  * t cp-hand  I  e r  1* ) 

(listening-port  *tcp-handler2*) 

(destination  *de s t - addre s s *  )  ) 
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() 

:get  table-instance-variables 
set  table- instance-variables 
i n i t ab 1 e - i n s t ance - var i ab 1 e s  ) 


( de fme  t hod  ( conve r s a t i on -wi t h - i r i s  :start-iris) 
() 
(progn 
(send  talking- port  :open 
: ac  t  i  ve 

ta Iking-port -number 
des  t  i  na  t  i  on 


tcp  will  begin  the  procedure  to  establish 

connection   (default   vs  :passive) 

port  number  of  destination  host 

machine  name  or  address  if  blank  and 

in  :passive  mode  local  machine  waits  for 

connec  t  i  on 

set  max  seconds  before  read  request  times 


30  ) 
(send  listening-port  :open 

: ac  t  i ve  ;  : pas  s  i  ve 

listening-port -numbe  r 

des  t  ina  t  i  on 

30  ) 
'"A  conversation  with  the  iris  machine  has  been  established" 


ou  t 


)  ) 


(defmethod  ( conve r s a t i on-wi t h- 
() 
(setq  * t cp- handl er 1  *  (send  ip 


r  i  s ) 
tcp-handler*  :get-port) 


* t cp- hand  1 e r 2*  (send  ip :  : * t cp -  hand  1 e r *  :get-port) 
talking-port    * t cp-handl e r  1* 
listening-port  * t cp-handl er2*  )  ) 


") 
") 
") 


(defmethod  ( conve r s a t i on-wi  t h - i r i s  :get-iris) 
() 
(let*  ((typebuffer 
(  1  eng t hbuf f er  " 

(buffer 
(buffer- length  1)  ) 
(progn 

(send  listening-port  :receive 
t ypebuf f e  r 
buf  f er -  1 eng t h 
30 

:  wa  i  t  ) 
(send  listening-port  :receive 
1 eng t hbuf f er 
4 

30 

:  wa  i  t  ) 
(setq  buf f er -  1 eng t h  (convert-string-to-integer  lengthbuf f er ) ) 
(setq  buffer  (make-string  buf  f  er  - 1  eng  t  h  :  in  i  t  i  a  1  -  e  lenient  (character 
listening-port  :receive 
buffer 

buf f er -  I eng t  h 
30 

:  wa  i  t  ) 
( ( equa 1 
( (equal 
( (equal 
(  t  nil) 


32))) 


(  send 


(  cond 


typebuffer  "I") 

t  ypebuf  f er  "R" ) 

t ypebu  f f e  r  "C" ) 

)  )  )  ) 


( conve  r  t 
( conver  t 
buffer) 


string- to- 
string- to 


integer 
real 


buffer ) ) 
buffer ) ) 


(defmethod  ( con ve r s a t i on -wi t h - i r i s  :put-iris) 
( ob  j  ec  t ) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  ( conve r t -number  -  to- s t r i ng  object)) 

((equal  (type-of  object)  'fixnum)  ( conve r t - numbe r - t o - s t r i ng  object)) 
((equal  (type-of  object)  'float)  ( conve r t - numbe r - t o - s t r i ng  object)) 
((equal  (type-of  object)  'string)  object) 
(t  "error")  )) 
( bu f f e r -  1 eng t h   (length  buffer)) 
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(typebuffer       (cond  ((equal  (type-of  object)  'bignum)  "I") 
((equal  (type-of  object)  'fixnum)  "I") 
((equal  (type-of  object)  'float)  "R" ) 
((equal  (type-of  object)  'string)  "C" ) 
( t  "C" )  ) ) 
(  1 eng t hbuf f e r    (convert-number-to-string  buf f er -  1 eng t h ) ) 
(* 1 oopvar i abl e*  0)  ) 
(progn 

(send  talking-port  : send 
t  ypebuf f er 
1 

nil 
ni  1  ) 
(if  (=  (length  1 eng t hbuf fer  )  4) 
(send  talking-port  : send 
1 eng t hbuf fer 
4 

nil 
nil  ) 
(progn 
(loopfor  *  1  oopvar i ab 1 e*  (length  1 eng t hbuf fer )  4 

(send  talking-port  :send  "0"  1  nil  nil)  ) 
(send  talking-port  : send  lengthbuffer  (length  1 eng thbuf f er )  nil  nil)  )  ) 
(send  talking-port  : send 
buffer 

buffer- 1 eng t h 
t 
nil  )  )  )  ) 

(defmethod  (conver sa t ion-wi th- i r i s  :stop-iris) 

(  ) 
(progn  (send  talking-port  :close)  (send  listening-port  rclose))  ) 
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All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 

* 

1 .      Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application's  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  select-host 

(defun   select-host    (host-name) 

b.  start-iris 

(defmethod    (:start-iris    conve rsa t i on-wi t h- i r i s ) 

() 

c.  get- iris 

(defmethod  (:get-iris  conversat ion-wi th- i ri s ) 
() 

d.  put-iris 

(defmethod  (:put-iris  conver sa t ion-wi t h- i r i s ) 
(obj  ec  t ) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  ( conver t -number  - t o- s t r i ng  object)) 

((equal  (type-of  object)  'fixnum)  (conver t -numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  ' s i ngl e - f 1 oa t )  ( conve r t - numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  'string)  object) 
(t  "error")  )) 

e.  stop- iris 

(defmethod  (:stop-iris  conversat ion-wi th- i r i s ) 

() 

f.  reuse-iris 

(defmethod    (:reuse-iris    conversat i on-wi th- i r i s ) 

() 
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2.      Code  and  Description 


;;;  -*-  Mode:  LISP;  Syntax:  Conmon- 1 i sp ;  Package:  USER  -*- 

:  handy  macro  to  have  in  the  send  message  farthur  down 

(defmacro  loopfor  (var  init  test  expl  &optional  exp2  exp3  exp4  exp5) 
' (prog  (  ) 

(setq  ,var  ,init) 
tag 

,  expl 

,  exp2 

,  exp3 

,  exp4 

,  exp5 

(setq  ,  v  a  r  (1+  ,var)) 

(if  (=  ,var  ,  test)  (return  t)  (go  tag))  )  ) 

(defun  convert-number-to-string  (n) 
(pr inc - t o- s t r ing  n)  ) 

(defun  conver t - s t r ing- t o- in t eger  (str  &optional  (radix  10)) 
(do  ((j  0  (+  j  1)) 

(n  0  (+  (*  n  radix)  ( di gi t -char -p  (char  str  j)  radix)))  ) 
( (=  j  ( length  st r  )  )  n)  )  ) 

(defun  f ind-pe r i od- index  (str) 
(catch  'exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  "."  0)) 
( throw  *exi  t  x)  )  )  )  ) 

(defun  ge t -  1 ef t s ide-of -  real  (str  &optional  (radix  10)) 
(do   ((j  0  (1+  j)) 

(n  0  (+  (*  n  radix)  (digi t -char -p  (char  str  j)  radix)))  ) 

((or  (null  (di gi t -char -p  (char  str  j)  radix))  (=  j  (length  str)))   n)  )  ) 

(defun  ge t - r i gh t s i de -of  -  real  (str  &optional  (radix  10)) 
(do  ((index  (1+  ( f ind-per iod- index  str))  (1+  index)) 
(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  ( dig i t -char -p  (char  str  index)  radix))))  ) 
((=  index  (length  str))  n)  )  ) 

(defun  conver t - s t r ing- to- real  (str  Aoptional  (radix  10)) 

(+  (float  (ge t -  1 ef t s i de-of - r eal  str  radix))  (ge t - r i gh t s i de -of  -  real  str  radix))  ) 


(defvar  *iris-portl*  1027) 

(defvar  *iris-port2*  1026) 

(defvar  *  1  oca  1  - t a  1 k-por t *  1500) 

(defvar  * loca 1  -  1  i s t en-por t *  1501) 


this  is  the  send  port 

this  is  the  receive  port 

this  is  the  local  send  port 

this  is  the  local  receive  port 


(defflavor  conversat ion-wi  th- i r i s  ( ( t a  1 ki ng-por t - numbe r        * i r i s -po r t 1  *  ) 

(listening-port- numbe  r     *iris-port2*) 
( 1  oca  1  - t  a  1 k-por  t -numbe  r    *Iocal-talk-port*) 
(local-listen-port -numbe  r  *locaI-listen-port*) 
( t  al king- s  t  ream) 
(listening-stre  am ) 
( de s t ina t i on-hos t -ob j ec t )  ) 
(  ) 
:ini table-instance-variables  ) 

(defmethod  (  :  i n i t - des t i na t i on  - hos t  conve r s a t i on -wi t h - i r i s ) 
( n  ame  -  o  f - h  o  s  t ) 
(setf  des t i na t i on-hos t -obj ec t  ( ne t : par se -hos t  name -of -hos t  )  )  ) 


138 


Symbolics  irisflavor.lisp 

(defmethod  (:start-iris  conversation -with- iris) 

(  ) 
(setf  talking-stre  am 

(tcp:open-tcp-st  ream  dest  inat  ion-host -object 
talking-port  - numbe  r 
local  - 1 alk-por t -numbe r  )  ) 
(setf  listening-stre  am 

( t  cp : open- t  cp- s  t  ream  destination-host-object 
listening-port  -numbe  r 
1  oca  1  -  1 i s t en-por t -  number  )  ) 
"A  conversation  with  the  iris  machine  has  been  established"  ) 

(defmethod  ( : reuse-iris  conver sa t ion-wi t h- i r i s ) 
() 
) 

(defun  read-string  (stream  num-chars) 
(let  ( (out  - st ring  "" ) ) 
(dotimes  (i  num-chars) 

(setf  out-string  ( s t r ing- append  out-string  (read-char  stream)))  ) 
ou  t - s  t  r  i  ng  )  ) 

(defmethod  (  : ge t - i r i s  conversat  ion-wi  th-iri  s) 
() 
(let*  ( ( typebuf f er    "  ") 
( 1 eng t  hbuf f e  r  "     " ) 
(buffer        "  ") 
(buffer- length  1)  ) 
(progn 

(setf  t  ypebuf f e  r 

(read-string  1 i s t ening- s t ream  1)  ) 
(setf  lengthbuffer 

(read-string  1 i s teni ng- s t ream  4)  ) 
(setf  buf f er - lengt h 

(convert-string- to-integer  lengthbuffer)  ) 
(setf  buffer 

(read-string  1 i s t ening- s t ream  buf f e r - 1 eng t h )  ) 

(cond  ((equal  typebuffer  "I")  (convert-st ring- to- integer  buffer)) 
((equal  typebuffer  "R" )  ( conve r t - s t r ing- to- real     buffer)) 
((equal  typebuffer  "C" )  buffer) 
(t  nil)  )  )  )  ) 

(defvar  *step-var*  0) 

(defun  my-wr i t e - s t r ing( s t r ing  stream) 
(let*  ( ( n  um-  chars  (length  string))) 
(dotimes  (i  num-chars) 

(write-char  (aref  string  i)  stream)  )  )  ) 

(defmethod  (  : pu t - i r i s  conve r s a t ion -wi  t h - i r i s ) 
( ob j  ec  t  ) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  (  conve r t - numbe r - t o- s t r i ng  object)) 

((equal  (type-of  object)  'fixnum)  ( conve r t - numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  ' s i ng 1 e - f 1 oa t )  ( conve r t - numbe r - t o - s t r i ng  object)) 
((equal  (type-of  object)  'string)  object) 
(t  "error")  )) 

( buf f er -  1  eng t h   (length  buffer)) 

(typebuffer       (cond  ((equal  (type-of  object)  'bignum)  "I") 
((equal  (type-of  object)  'fixnum)  "I") 
((equal  (type-of  object)  'single-float)  "R") 
((equal  (type-of  object)  'string)  "C" ) 

(t  "C")  )) 

(lengthbuffer    (convert-n umb er-to-string  buffer-length))  ) 
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(progn 

(my -wr  i t e  -  s t r ing  typebuffer  t a lki ng- s t ream) 
(send  t a  Ik ing- s t ream  :  force  -  output ) 
(if  (=  (length  1 eng t hbuf f e r  )  4) 

(wr  i t e - s t r i ng  1 eng t hbuf fe r  t a  Iking- s t ream) 
(progn 

(loopfor  *step-var*  (length  1 eng t hbuf fer )  4 
(write-string  "0"  t a  Ik ing- s t ream)  ) 

(my -wr  i t e- s t r ing  lengthbuffer  t aiking- s t ream)  )  ) 
(send  t alking- s t ream  : force  - ou tput ) 
(my -wr i  t e - s t r ing  buffer  t a  1 ki ng - s t ream) 
(send  t alking- s t ream  :  force  - outpu t )  )  )  ) 

(defmethod  (:stop-iris  conversat  ion-wi  th-iris) 

() 
(progn  (send  t a  1 k ing- s t ream  :close) 
(send  1 i s t eni ng- s t ream  :close)  )  ) 

(defun  select- host  (host-n  ame  ) 

(send  talk  : i n i t -de s t i na t i on  - hos t  host-name)  ) 
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APPENDIX  A  -  TEST  AND  UTILITY  PROGRAMS 

1.      gprog.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from  iris2.  It  must  be  run  in  conjunction  with 
gprog2.c  to  function  properly,  as  the  port  assignments  are  hardcoded.  Since  it  is  the 
server  program,  it  must  be  started  before  gprog2.c. 

b.  Code  and  Description 

/*  this  is  file  gprog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  snared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  SERVER  side  program  and  runs  first!!!. 

*/ 

#include  "shared. h" 
#inc 1 ude  "gl . h" 
#include  "device. h" 

main( argc , argv) 

int  argc;    /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


( 


Machine  remot  emachine ;  /*  structure  for  remote  machine  */ 

char  o the r_mach ine [50] ;  /*  name  of  other  machine  */ 

char  mybuf f e r [LARGESTREAD] ;      /*  received  data  */ 

char  ou t going [LARGESTREAD] ;      /*  outgoing  message's  buffer  */ 

int  mybuf ferl [LARGESTREAD / INTEGER, SIZE] ;  /*  received  integer  data  */ 

int  outgoingl [LARGESTREAD/ INTEGER, SIZE] ;  /*  outgoing  integer  message's  buffer  */ 

float  mybuf f e r2 [LARGESTREAD /FLOAT_ SIZE] ;  /*  received  float  data  */ 

float  outgoing2[LARGESTREAD/FLOAT_SIZE] ;  /*  outgoing  float  message  buffer  */ 

long  noutgoing;  /*  size  of  the  outgoing  message  */ 
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char  t  emp  [10]; 

long  count  =  0; 

char  rece i ved_t ype ( ) ; 

char  type_received; 

i  n  t  el  erne  nt  s_received; 

1 ong  i ; 

long  j  =  0; 


gprog.c 

/*  temp  array  used  to  make  outgoing  message  */ 
/*  message  counter  */ 


/*  temp  loop  variable  */ 

/*  variable  to  control  message  sending  */ 


/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2) 

( 

pr int f ( "GPROG:  incorrect  argument  count!   use  gprog  <alias>\n"); 
exi  t( 1 ) ; 

} 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

if(  argc  ==  2  ) 

I 

strcpy(  o t her_machi ne ,  "npscs-"  ); 
strcat(  o t her_mach ine ,  argv[l]  ); 

) 
else 

strcpy(  o t he r_mach i ne ,  "npsc s - i r i s 1 "  ); 

/*  create  a  path  to  a  particular  machine  (irisl  default)  */ 
/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  fifth  argument  indicates  whether  the  processes  should 

act  as  a  server  or  a  client, 
the  sixth  argument  is  the  returned  pointer  to  the  structure 
remot  emachine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 
the  seventh  argument  is  the  amount  of  freespace  desired  for  dynamic 
memory  allocation  during  execution  of  the  program. 
*/ 
dynamicmachi  nepath( 1 , o t her_machine ,1,2, "server" ,&remotemach  ine , 2000000) ; 

/*  the  loop  for  polling  the  shared  segment  */ 
whi le(TRUE) 

( 

/*  make  an  outgoing  message  */ 

strcpy( out  going, "GPROG  ORIGINATED  MESSAGE:  "); 

count  =  count  -  1; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1  en ( ou t go i ng ) ; 

outgoing2[0]  =  count; 

/ *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
i  f(receiver_has_data (&r  emo t  emach  ine)) 

( 

t ype_rece i ved  =  rece i ved_ t ype (&r  emo t emach i ne ) ; 
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printf("The  message  received  by  GPROG  is  of  type  %c    \n" , 
t  ype_rece  i  ved )  ; 

switch  ( t ype_rece i ved) 
( 

case  CHARACTER, ARRAY_TYPE : 

e 1  emeu t s_rece i ved  =  number_rece i ved(&r  emot emach i ne ) ;  ' 

print f( "The  message  received  by  GPROG  is  %d  elements  long!\n' 
e  1  eme nt  s_received) ; 

read_charac t ers  (&remot  emachine ,  mybuffer,  e 1 emen t s_rece i ved ) 
break ; 

case  INTEGER_TYPE : 

read_ integer (&r  emot emachine ,mybuf  f er  1 )  ; 
break ; 

case  FLOAT_TYPE: 

read_ float  (&r  emot  emachine  ,mybuf f er2)  ; 
b  r  e  ak  ; 

) 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 

pr in t f ( "GPROG  has  received  the  following  data:\n"); 

switch  (type  received) 

I 

case  CHARACTER_ARRAY_TYPE : 

f o r ( i  =0 ;  i  <  e 1 eme nts_received;  i+=l) 

I 

p  r  i  n  t  f ( "%c  " ,mybu  ffer[i]); 

} 

b  r  e  ak ; 

case  INTEGER_TYPE : 

print f ("%d"  .mybuffer 1 [0] ) ; 
break ; 

case  FLOAT  TYPE: 

print f("%f "  ,mybuffer2[0]); 
break ; 

) 

pr  in t  f ( "\n" ) ; 


/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(sender_i  s_f ree(&remot  emachine  )  ) 

( 

if((j  %   3)  ==  0) 

wri  te_characters (&remot  emach  ine.outgoing.noutgoing) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_i s_free (&r emot emach ine  )  )  /*  do  nothing  */  ; 

i  f  (  (  j  %  3  )  ==  1 ) 

wri  te_integer (&remot  emach  ine , outgoingl ) ; 

/ *  wa  i  t  until  me  ssage  sent  before  att  emp  ting  to  send  another  *  / 
wh i 1 e (  ! sende r_i s_f ree (&remot emach i ne )  )  /*  do  nothing  */  ; 

if((j  %   3)  ==  2) 

wr  i  t  e_f loa  t (Aremot emach  ine ,outgoing2) ; 


) 
else 


++J  ; 
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/*  assume  socket  connection  broken  */ 
pr in t f ( "Sender  wasn't  free!   Termina t ing. . . \n" ) 
break ; 


)    /*  endif  wh i le  TRUE  */ 

/ *  get  rid  of  the  path  to  the  other  machine 
de 1 e  t  emach  i  nepa  t  h (&r  emot  emach  ine ) ; 
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2.      gprog2.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.    By  command  line 

argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 

The  default  is  to  receive  messages  from    irisl.    It  must  be  run  in  conjunction  with 

gprog.c  to  function  properly,  as  the  port  assignments  are  hardcoded.    Since  it  is  the 

client  program,  it  be  started  after  gprog.c  is  ready  for  it. 

b.  Code  and  Description 

/*  this  is  file  gprog2.c 

It  is  a  sample  top  level  graphics  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  CLIENT  side  program  and  runs  second!!!. 

•/ 

# include  " shared. h" 
#define  TRUE  1 

ma  in( argc , argv ) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


I 


Machine  remot  emachine ;  /*  structure  for  remote  machine  */ 

char  o the r_machine [50] ;  /*  name  of  other  machine  */ 

char  mybuf fer [LARGESTREAD] ;  /*  received  data  */ 

char  ou t go i ng [LARGESTREAD] ;  /*  outgoing  message's  buffer  */ 


int  mybuf  f  e  r  1  [LARGESTREAD/ I  NTEGER_  SIZE] 
int  out  go ingl[ LARGESTREAD/ INTEGER_SIZE] 
float  mybuffer2[LARGESTREAD/FLOAT_SIZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  me  ssage's  buffer  * / 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  */ 


long  noutgoing;  / *  size  of  the  outgoing  me  s  s  a  g  e  * / 

c  li  a  r  t  emp  [10];  /  *  t  emp  array  used  to  ma  ke  outgoing  me  s  sage  */ 

long  count  =  0;  /*  message  counter  */ 

char  rece i ved_ t ype ( ) ; 
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char  t ype_rece i ved ; 

int  e  1  emen t s_rece i ved; 

long  i;  /*  temp  loop  variable  */ 

longj=0;  /*  variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2  ) 

I 

pr in t f (  "GPROG2 :  incorrect  argument  count!   use  gprog2  <a 1 i as>\n"  )  ; 
exi  t(  1 )  ; 

) 

/*  pull  out  the  n ante  of  the  other  string,  if  it  exists  * / 

if(  argc  ==  2  ) 

{ 

strcpy(  o t her_machine ,  "npscs-"  ); 
strcat(  o t her_machine ,  argvfl]  ); 

) 
else 

strcpy(  other_machine ,  "npsc s - i r i s2"  ); 

/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  sixth  argument  is  the  returned  pointer  to  the  structure 
r  emo  t  ema  chine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sends  em  id, 
and  the  returned  receives  em  i  d . 
*/ 
machinepath( 1 , o ther_machine ,2,1, "client"  ,&remot  emach  ine ) ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
whi le(TRUE) 

( 

/*  make  an  outgoing  message  */ 

s t rcpy ( ou t going," IRIS  1  ORIGINATED  MESSAGE:  "); 

count  =  count  +  1; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1  en ( ou t goi ng ) ; 

outgoing2[0]  =  count; 

/ *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
i  f(receiver_has_dat  a(&remo t  emach  ine)) 
I 
t ype_r ece i ved  =  rece i ved_ t ype (&remot emach i ne ) ; 

printf("The  message  received  by  IR1S1  is  of  type  %c    \n" , 
type_received) ; 

switch  (type_received) 

( 

case  CHARACTER_ARRAY_TYPE : 

e  1  emen t s_rece i ved  =  numbe r_rece i ved(&remot  emach ine ) ; 
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printf("The  message  received  by  IRIS1  is  %d    elements  long!\n' 
e 1  erne nt  s_received) ; 

read_ characters (&remot  emach  i  ne  ,mybuf  f e  r , 
elements_received) ; 
break; 

case  INTEGER_TYPE : 

read_integer (&remo  t  emach  ine .mybuf  f e  r 1 ) ; 
break ; 

case  FLOAT_TYPE: 

read_f 1 oa t (&remot  emach  i  ne  , mybuf f er2 )  ; 
break ; 

) 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
pr in t f ( " IRIS1  has  received  the  following  data:\n")  ; 

switch  ( type_rece i ved) 
I 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  e 1 emen t s_rece i ved ;  i+=l) 

( 

pr  in  t  f ( "%c" , mybuf fe  r [ i ] ) ; 

I 
break ; 

case  INTEGER_TYPE : 

print f ("%d" .mybuf fer 1 [0] ) ; 
break ; 

case  FLOATTYPE: 

print f("%f" ,  mybuf fer2[0] ) ; 
break; 

) 

print f ("\n" ) ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  me  ssages  */ 

if(sender_is_free(&r  emo  t  ema  chine)) 

I 
if((j  %  3)  ==  0) 

wri  te_characters (&remot  emach ine , outgoing, noutgoing) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_i s_f ree  (&remot  emachine )  )  /*  do  nothing  */  printf("2"); 

if((j  %  3)  ==  1) 

wr  i  te_integer  ( &r  emo t  emach  ine.outgoingl) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_f ree (&remot emach ine )  )  /*  do  nothing  */  printf("3"); 

i  f  (  ( j  %  3  )  ==  2  ) 

wr  i  t  e_f loa  t (&remot  emach  ine ,outgoing2) ; 

++j ; 

) 
else 

I 

/*  assume  socket  connection  broken  */ 
p  r  i  n l f ( " Sender  wasn't  free!   Te  rm  i  n  a  t  i  n  g .  .  . \ n "  )  ; 
break: 
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/*  at  this  point,  you  can  do  the  rest  of  the  display  loop  */ 

)    /*  end  if  whi le  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 
de 1 e  t  emach  i  nepa  t  h (&r  emot  emach  ine  )  ; 
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3.      prog.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  iris2.  It  must  be  run  in  conjunction  with  prog2.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


#include  " shared. h" 
#define  TRUE  1 


ma  i  n( argc , argv ) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


Machine  remot  emach i ne 1 
Machine  remo  t  emach  i  ne2 
char  o t he r_machine [50] 
char  mybuf  f  er  [LARGESTREAD]  ; 
char  ou t going [LARGESTREAD] ; 


/*  first  structure  for  remote  machine  */ 

/*  second  structure  for  remote  machine  */ 

/ *  n  ame  of  other  ma  chine  * / 

/*  received  data  */ 

/*  outgoing  message's  buffer  */ 


int  mybufferl[LARGESTREAD/INTEGER_SIZE] 
int  out  go ingl[ LARGESTREAD/ INTEGER_S I ZE ] 
float  mybu  f  f e  r  2 [ LARGESTREAD /FLOAT_S I ZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 
long  n outgoing; 
char  t  emp [10]; 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer  *  / 

/*  received  float  data  * / 

/*  outgoing  float  message  buffer  */ 
/*  size  of  the  outgoing  me  s  s  a  g  e  * / 
/*  temp  array  used  to  make  outgoing  message  */ 


long  count  =  0; 

char  rece i ved_ t ype(  ) 

char  type_received; 


/*  message  counter  */ 
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nt  el  erne  nts_received: 

ong  i:  /*  temp  loop  variable  */ 

ong  j  =  0:  /*  variable  to  control  message  sending  */ 

/ *  pull  out  the  string  fr  om  the  a  r  g  ume  n  t  list  * / 
f (argc  >  2) 

pr in t f ( "PROG:  incorrect  argument  count!   use  prog  <alias>\n"); 
exi  t (  1  )  ; 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
f (  argc  ==  2  ) 

strcpy(  o t he r_machi ne ,  argv[l]  ); 

else 

strcpy(  other_machine,  "npscs - i r i s2"  ); 

/*  create  a  pair  of  paths  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  receiver  or  a  broadcaster. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
remot emachine 1  or  remot emach ine2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 

•/ 

dynamicmachinepa ths (2 , 1 , o t  her_machine ,2,1, "receive"  ,&remot  emachine 1 ) ; 

sleep(5);    /*  to  let  both  sides  set  up  receiving  channels  first  */ 
dynami  cmachi  nepaths(2,l,othe  r_machine ,4,3,"broadcast"  ,&remot  emach  ine2 ) ; 

/*  the  loop  for  polling  the  shared  segment  limited  to  avoid  send  buffer 

ove  r  f 1 ow  * / 
whi le(TRUE) 

I 

/*  make  an  outgoing  message  */ 

st rcpy( out  going, "PROG  ORIGINATED  MESSAGE:  "); 

coun  t  =  coun  t  +  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1 en( ou t go i ng ) ; 

outgoing2[0]  =  count; 

/*  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
i  f(receiver_has_dat  a(&remot  emach  i  ne 1 ) ) 

( 
t ype_rece i ved  =  r ece i ved_ t ype (&remot  emach i ne 1 )  ; 

printf("The  message  received  by  PROG  is  of  type  %c    \n"  . 
t  ype_r ece  i  ved ) ; 

switch  (type_received) 
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( 

case  CHARACTER_ARRAY_TYPE : 

e 1 emen t s_rece ived  =  numbe r_r ece i ved (&remo  t emach i ne  1  )  ; 

printf("The  message  received  by  PROG  is  %d  elements  long!\n" 
e 1  erne  nts_received): 

read_ characters (&remo t  emach  i  ne 1 .mybu  f  f e  r , 
e 1  erne  nts_received); 
break ; 

case  INTEGER_TYPE : 

read_integer (&remot  emach  ine 1  ,  my buffer  1 )  ; 
break ; 

case  FLOAT_TYPE: 

read_float (&remot  emach  i  nel  ,mybuf f er2)  ; 
break : 

) 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
printf("PROG  has  received  the  following  data:\n"); 

switch  ( t ype_rece i ved) 

( 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  e 1 emen t s_rece ived ;  i+=l) 

I 

pr  in  t  f ( "%c" ,mybuf f er [ i ] ) ; 

) 
break; 

case  INTEGER_TYPE : 

print f( "%d" ,mybuf f er 1 [0] ) ; 
break : 

case  FLOAT_TYPE: 

print f("%f" ,mybuf fer2[0] )  ; 
break ; 

) 

p  r  i  n  t  f  (  "  \  n  "  ) ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(sender_i  s_f ree (&remo t  emach ine2) ) 

( 
if((j  %  3)  ==  0) 

wr  ite_characters (&r  emo t  emach  ine2,outgoing,noutgoing) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 

wh  i  1  e (  ! sende r_i s_f ree (&r  emo t  emach i ne2 )  )  /*  do  nothing  printf("2")*/ 

if((j  %  3)  ==  1) 

wr  i  te_integer (&remo  t  emach  ine2,outgoingl ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while!  ! sende r_ i s_f ree (&r emo t  emach i ne2 )  )  /*  do  nothing  printf("3")*/ 

if((j  %   3)  ==  2) 

wr  i  t  e_f 1 oa  t (&remo t  emach  ine2,outgoing2); 

/*  wait  until  message  sent  before  continuing  */ 

wh i  1 e (  ! sende r_i s_f ree l&remot  emach i ne2 )  )  /*  do  nothing  p r i n t f ( " 4"  )  *  / 

+  +  j  ; 
} 
else 
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/*  assume  socket  connection  broken  */ 
printf(" Sender  wasn't  free!\n"); 
break; 


I*    at  this  point,  you  can  do  the  rest  of  the  display  loop  */ 

)    /*  end  if  wh i le  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 
de 1 e  t  emach  inepa  t h (&remot  emachine  1  )  ; 
de  1  e  t  emach inepa  t h  (&remot  emachine 2 ) ; 
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a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  irisl.  It  must  be  run  in  conjunction  with  prog.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog2.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


#include  " shared. h" 
#define  TRUE  1 


ma  in( argc , argv ) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


Machine  remot emachine 1 ; 
Machine  r emot emachine2 ; 
char  o ther_machine [50] ; 
char  mybuffer[LARGESTREAD]  ; 
char  outgoing[LARGESTREAD]  ; 


/*  first  structure  for  remote  machine  */ 

/*  second  structure  for  remote  machine  */ 

/*  name  of  other  machine  */ 

/*  received  data  */ 

/*  outgoing  message's  buffer  */ 


int  mybufferl[LARGESTREAD/INTEGER_SIZE] 
int  outgoingl[LARGESTREAD/INTEGER_SIZE] 
float  mybuf fer2[LARGESTREAD/FLOAT_SIZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 
long  noutgoing; 
char  t  emp [10] ; 


/ *  received  integer  data  * / 

/*  outgoing  integer  message's  buffer  */ 

/  *  received  float  data  * / 

/*  outgoing  float  message  buffer  */ 
/*  size  of  the  outgoing  message  */ 
/*  temp  array  used  to  make  outgoing  message  */ 


long  count  =  0; 

char  rece i ved_t ype( ) ; 

char  t ype_rece i ved; 


/*  message  counter  */ 
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int  e  lemen t s_rece i ved; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  (*    variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2  ) 

{ 

pr int f ( "PROG2 :  incorrect  argument  count!   use  gprog2  <alias>\n"); 
exi  t( 1) ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 
if(  argc  ==  2  ) 

( 

strcpy(  other  machine,  argv[l]  ); 

} 
else 

strcpy(  other_machine ,  "npsc s - i r i s2"  ); 

/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
remot emachinel  or  remot emachine2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 
*/ 
dyrxami  cmachi  nepa  ths  (2,1,  other_machine  ,3,4,  "receive"  ,&remot  emachineZ  )  ; 

sleep(5);   /*  to  let  both  ends  of  the  process  get  set  up  */ 

dyn ami cmachi nepa ths (2,1, ot her_mach  ine, l,2,"broadcast" ,&remot  emach  ine 1 ) ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
while (TRUE) 

{ 

/*  make  an  outgoing  message  */ 

st rcpy( out  going, "PROG2  ORIGINATED  MESSAGE:  "); 

coun  t  =  count  +  1 ; 

outgoingl[0]  =  count; 

noutgoing  =  s t r 1 en( ou t goi ng ) ; 

outgoing2[0]  =  count; 

/  *  is  there  (.lata  in  the  shared  se  gme  n  t  ?  *  / 
if(receiver_has_dat  a(&remot  emach i  ne2 ) ) 

( 
t ype_rece i ved  =  r ece i ved_t ype  (Aremot  emach i ne2 ) ; 

printf("The  message  received  by  PROG2  is  of  type  %c  \n", 
t  ype_rece  i  ved) ; 

switch  ( type_rece i ved) 
( 
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case  CHARACTER_ARRAY_TYPE : 

e lemen t s_recei ved  =  nurnbe r_rece i ved(&remot emach ine2  )  ; 

printf("The  message  received  by  PR0G2  is  %d  elements  long!\n' 
e 1  erne nt  s_received) ; 

read_charac  ters (&remot  emach i  ne2  , my buffer , 
e 1  erne  nts_received) ; 
break ; 

case  INTEGERJTYPE : 

read_integer (&remot  emach  ine2  ,mybuf f er 1 )  ; 
break; 

case  FLOAT_TYPE: 

read_ float  (&remot  emach ine2  ,mybuf f er2)  ; 
break; 

} 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
pr in t f ( "PROG2  has  received  the  following  data:\n"); 

switch  ( type_rece i ved) 

I 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  e lemen t s_recei ved ;  i+=l) 

I 

pr  in  t  f ( "%c" .mybuf fer [ i ] ) ; 
) 
break; 

case  INTEGERJTYPE : 

print f ("%d" .mybuf fer 1 [0] ) ; 
break; 

case  FLOATTYPE: 

print f ("%f  " .mybuf fer2[0] ) ; 
break ; 

) 

pr  in t  f ( "\n" ) ; 

) 

/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(sender_is  free (&remot  emach  i  ne 1 ) ) 

( 
if((j  %   3)  ==  0) 

write_characters  (&remot  emach ine 1 ,outgoing,noutgoing)  ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_f ree(&remot  emachine 1 )  )  /*  do  nothing  pr in t f ( "2"  )  * / 

if((j  %  3)  ==  1) 

wri  te_integer (&remot  emach  inel.outgoingl); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sende r_i s_free(&remot emach i ne  1  )  )  /*  do  nothing  pr in t f ( " 3"  )  *  / 

if((j  %  3)  ==  2) 

wr  i  t  e_f loa  t (&remot  emach  inel ,outgoing2) ; 

/*  wait  until  message  sent  before  continuing  */ 

wh i 1 e (  ! sende r_i s_free (&remot  emach i ne 1  )  )  /*  do  nothing  pr in t f ( "4"  )  *  / 

+  +  j  : 
} 

else 
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/*  assume  socket  connection  broken  */ 
print f( "Sender  wasn't  free!   Termina t i ng . . . \n " ) 
break; 


)    /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine 
de 1 e  t  emach  i  nepa  t  h (&r  emot emach  i  ne2 ) ; 
de  1  e  t emach i nepa  th (&remot  emach ine 1 ) ; 
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a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  remove  all  shared  memory  segments  owned 
by  the  user.  By  command  line  argument,  selective  segments  can  be  removed. 

b.  Code  and  Description 

*  * 

* 
* 

* 

* 

* 
* 

*  * 
+  +  **  +  *****  +  +  +  **♦*  +  +  **  *****************************************  **************** 

*  * 

*  HISTORY:  * 

*  * 

* 
* 
* 
* 

* 
Removes  shared  memory  segments  identified  on  command  line.     * 

**********  +  *****  +  *♦+**  +  +  ♦*  +  **♦**  +  ***♦  +  **  +  *****♦♦♦  +  ■),****  +  »  +  +  ***♦,♦*  +  ****♦♦***♦** 

*  * 

*  RECORD  OF  CHANGES  * 


*  TITLE 

* 

*  MODULE 


*  VERSION 

*  DATE 

*  AUTHOR 


* 

VERSION 

* 

* 

DATE 

* 

* 

AUTHOR 

* 

* 

DESC. 

* 

In t er -Compute r  Communication  Package 

rmshare  .  c 

1.0 

25  February  1988 

Theodore  H.  Barrow 


1  .0 

25  February  1988 

Theodore  H.  Barrow 


*Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Ve r s * 

************  +  ****  ********************  ***********************************  ****** 

*  *  *  *  *  *        * 

*  *  * *         * 

*****************************************************************************/ 
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#include  <errno.h> 

# include  <sy s / sy smac ros . h> 

#include  <stdio.h> 

#include  <sy s / t ype s . h> 

#include  <sys/ipc.h> 

#include  <sys/shm.h> 

#  i  nc 1 ude  <g 1  . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE   IRIS4D 

fF  C  I  S  C 

#define  MACHINE   IRIS3000 
#endi  f 

extern  in  t  er  rno ; 

ma  in(  argc,  argv  ) 

int  argc;        /*  argument  count  */ 
char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 

( 

int  first  =  1 ; 

int  last   =  1000; 

key_t  i ; 

int  shmid; 

key_t  key; 

static  struct  shmid_ds  buffer; 

/*  set  the  number  of  shared  memory  keys  to  remove  */ 
i  f ( argc  >  1 ) 

{ 

for(  i=first;  i<argc;  i++  ) 

( 
key  =  atoi(  argv[i]  ); 

if(  (shmid  =  shmget(  key,  0,  0))  ==  -1  ) 

( 
i  f (  errno  !=  ENOENT  ) 

I 

write_error(  shmid,  key,  errno  ); 

} 
) 
else 

I 

if(  shmctl(  shmid,  IPC_RMID,  &buffer  )  ==  - 1  ) 

{  . 
write_error(  shmid,  key,  errno  ); 

) 
else 

write_done(  shmid,  key  ) ; 
)   /*  if(  (shmid  =  shmget(  i  ,  0 ,  0  ) )  ==  -  1  )  * / 
|   /*  for  */ 

) 
else 

( 

for(  i=first;  i<last;  i++  ) 
( 

if(  (shmid  =  slimget(  i,  0,  0))  ==  -1  ) 
( 

i  f (  errno  !=  ENOENT  ) 
( 

write_error(  shmid,  i,  errno  ); 

) 
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) 

else 


if(  shmctl(  shmid.  IPC_RMID.  &buffer  )  ==  - 1  ) 

I 
write_error(  shmid,  i,  errno  ); 

) 
else 

write_done(  shmid,  i  ); 
)   /*  if(  (shmid  =  shmget(  i,  0,  0  ))  ==  -1  )  */ 
/*  for  */ 


print f(  "\nCompl e t ed . \n"  ); 
)   /*  main( )  */ 

write_error(  shmid,  key,  error  ) 
int  shmid; 
key_t  key: 
int  error; 

I 

print  f (  "\nShared  Memory  ID%d  (key  %d)    caused  error  %d .  "  , 
shmi  d,  key,  error  ); 

)   /*  wr i t e_error  (  )  */ 

write_done(  shmid,  key  ) 
int  shmid ; 
key_t  key; 

( 

printf(  "\nShared  Memory  ID  %d  (key  %d)  removed.",  shmid,  key  ) 

(   /*  write_done()  */ 
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6.      testshare.c 


a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  print  current  parameters  for  all  active 
shared  memory  segments.  By  command  line  argument,  selective  segments  can  be 
printed. 

b.  Code  and  Description 

* 
* 
* 

* 

* 
* 
* 
* 

*  * 

*  HISTORY:  * 

*  * 

* 
* 
* 

+ 
* 
* 
* 
* 


* 

TITLE 

* 

* 

MODULE 

* 

* 

VERSION 

* 

* 

DATE 

* 

* 

AUTHOR 

* 

In  t  e  r  -Compu  t  er    Corrmun  ica  t  i  on    Package 

testshare.c 

1.0 

25  February  1988 

Theodore  H.  Barrow 


1.0 

25  February  1988 

Theodore  H.  Barrow 

Determines  which  shmid  values  are  used  and  what  their 
par  anie  t  e  r  s  are. 


*  VERSION 

*  DATE 

* 

*  AUTHOR 

*  DESC. 

* 

*  * 

*  RECORD  OF  CHANGES  * 


* Ve  r  s  i  o  n  *   Da  t  e   *   Au  t  h  o  r 

Ch  a  n  g  e  De  script  ion 


*  *   Affected    *Reqd* 

*    Modules    *Ve r s * 

***♦****+***************.****♦******  +  **  +  *  +  +  ****  +  ******  +  ***********************<•. 

*  *         *  *  *  *     * 

*  *  *  *     * 
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#include  <errno.h> 

#include  <sy s / sy smac ros . h> 

#  i  n  elude  <stdio.h> 

#include  <sy s / t ype s . h> 

#include  <sys/ipc.h> 

#include  <sys/shm.h> 

#i  nc I ude  <g 1  . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE   IRIS4D 

#e  1  se 

#define  MACHINE   IRIS3000 

#endi  f 

extern  in  t  er  rno; 

ma  i  n  (  ) 

( 

in  t  first  =  1 ; 

int  last   =  1000: 

int  i  ; 

int  shmid; 

for(  i=first;  i<last;  i++  ) 

( 

if(  (shmid  =  shmget(  i,  0,  0))  ==  -1  ) 
{ 
i  f (  errno  !=  ENOENT  ) 

( 

write_error(  shmid,  i,  errno  ); 

) 
) 
e  1  se 

( 

if(  wri te_s t rue t (  shmid  )  ==  - 1  ) 
write_error(  shmid,  i,  errno  ); 
)   /*  if(  (shmid  =  slimget(  i  ,  0 ,  0  )  )  ==  -  1  )  */ 
)   /*  for  */ 

print f(  "\nCompl e t ed . \n"  ); 

)   /♦  main()  */ 

write_error(  shmid,  key,  error  ) 
int  shmid; 
key_t  key; 
int  error; 

{ 

print  f (  "\nShared  Memo r y  ID  %d  (key  %d )  caused  error  %d . " , 
shmi  d,  key,  error  ); 

)   /*  wr i t e_e r ror ( )  */ 

struct     shmid_ds    *get_struct(     slunid    ) 
int     s  lim  i  d  ; 

I 

static  struct  shmid_ds  buffer; 

if(  shmctl(  shmid,  IPC_STAT,  &buffer  )  ==  -  1  ) 
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return(  (struct  shmid_ds  *)-l  ) 

I 
else 

i e  t urn(  &buf f er  )  ; 

)   /*  ge t_s  t  ruct ( )  */ 


wr  i t e_s t rue t (  shmid  ) 
i  n  t  shmid ; 


struct  shmid_ds  *buf; 

if(  (int)(buf  =  get_struct( 
return(  (int)buf  ); 


shmid  ))  ==  -1  ) 


Pr 
pr 
pr 

P>" 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
Pr 
pr 
pr 


nt  f 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 
ntf 


pr  i  n  t  f 


return 


AnSh 

"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 
"\n 

0  ); 


a  red  Memory  ID  %d  has  the  f ol lowi  ng  structure:", 
shm_perm  has  the  following  structure:"  ); 


shmid  ) ; 


c u i d  is  %d . 

c g i d  is  %d . " 

u  i  d  is  %d  . " , 

g i d  is  %d . " , 

mode  i  s  %o  . " 

s  e  q  is  %d  . " , 

key  i  s  %d  . " , 

s hm_ s e g s z  is  %d 

s hm_ r e g  is 

s  hm_ 1 p  i  d  is  %A . 

shm_cpi  d  i  s  %d  . 

shm_na t t  ch  i  s  % 

shm_cna t t ch  is1 

shm_a  t  ime  i  s  %d 

shm_dt  ime  i  s  %d 

shm  c  t  ime  i  s  %d 


buf ->shm_pe  rm. cui d  ); 
buf ->shm_pe  rm. cgi d  ); 
buf ->shm_perm. uid  ); 
buf ->shm_perm.  g id  ); 

buf ->shm_pe rm.mode  ); 
buf ->shm_pe rm. seq  ); 
buf ->shm_perm. key  ); 

o  r  %x  . " ,  b  u  f - >  s  hm_  segsz,  buf->s  hm_  s  e  g  s  z  ) 
a  structure  incompletely  defined  in  region.h!" 
b  u  f  -  >  s  lim_  1  p  i  d  )  ; 
buf ->shm_cpi  d  )  ; 
,  buf ->shm_na t t ch  ); 
",  buf ->shm_cna t t ch  ); 
buf ->shm_a t  ime  ) 
buf ->shm_dt  ime  ) 
buf ->shm_segsz  ) 


)   /*  wr i t e_s t rue t  (  )  */ 
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